Тут проблемка есть. Больше даже наверное организационная.
В общем, такая ситуация, что есть проблема «последней» рабочей версии.

Например, есть у нас программа, в которой есть модули. И вот был у нас модуль для показа результата поиска. Мы этот модуль сделали и отдали. А сами посчитали, что работа этого модуля нехорошая, и стоит бы его переделать. И вот начинаем мы его переделывать, проходит день-два. И вдруг приходит жалоба от клиентов, что там у нас плохо работает (или что более реально, некрасиво выглядит) поиск и его нужно очень быстро переделать. Однако щас мы пользуемся SourceSave, и в нем ведем наш проект. Возникает вопрос, что же нам теперь делать? За эти несколько дней, мы начали переделывать систему для нового модуля поиска (возможно еще какие-то другие модули), и что же теперь делать: копировать все это счастье, возвращаться к «примерно последней работающей версии», делать в ней изменения и переделанную прогу отдавать клиентам. А уже потом обратно затирать изменения и возвращаться к нашей новой переделываемой системе.

Как можно решить такую проблему?

Здравствуйте, Аноним, Вы писали:

А>Например, есть у нас программа, в которой есть модули. И вот был у нас модуль для показа результата поиска. Мы этот модуль сделали и отдали. А сами посчитали, что работа этого модуля нехорошая, и стоит бы его переделать. И вот начинаем мы его переделывать, проходит день-два. И вдруг приходит жалоба от клиентов, что там у нас плохо работает (или что более реально, некрасиво выглядит) поиск и его нужно очень быстро переделать. Однако щас мы пользуемся SourceSave, и в нем ведем наш проект.
А>Как можно решить такую проблему?

Использовать систему управления версиями, поддерживающую бранчи.

Можно оставить существующий инструментарий, но при выпуске последней версии "в люди" и старте новой версии, инициируйте новый проект.
Т.е. для последних 1-3 версий (все зависит от числа ваших конечных пользователей, частоты выпуска новой версии и частоты обновления версий пользователями) всегда должен быть отдельный "закрытый проект" и при необходимости выпустить новый билд на старой версии расконсервируйте исходники этой версии.

Шаповаленко Денис

Здравствуйте, denis_orri, Вы писали:

_>Можно оставить существующий инструментарий, но при выпуске последней версии "в люди" и старте новой версии, инициируйте новый проект.
_>Т.е. для последних 1-3 версий (все зависит от числа ваших конечных пользователей, частоты выпуска новой версии и частоты обновления версий пользователями) всегда должен быть отдельный "закрытый проект" и при необходимости выпустить новый билд на старой версии расконсервируйте исходники этой версии.

А потом вручную "мердждить" туда, где ведется ручная разработка.
В общем лучше использовать тул, который нормально поддерживает бранчи

Зачем вручную? Можно их нацелить на одну базу данных исходников и выполнять только коммит....
Не, ну если есть нормальный инструмент, то ради бога....
А потом вручную "мердждить" туда, где ведется ручная разработка.

Здравствуйте, Аноним, Вы писали:

А>Например, есть у нас программа, в которой есть модули. И вот был у нас модуль для показа результата поиска. Мы этот модуль сделали и отдали. А сами посчитали, что работа этого модуля нехорошая, и стоит бы его переделать. И вот начинаем мы его переделывать, проходит день-два. И вдруг приходит жалоба от клиентов, что там у нас плохо работает (или что более реально, некрасиво выглядит) поиск и его нужно очень быстро переделать. Однако щас мы пользуемся SourceSave, и в нем ведем наш проект. Возникает вопрос, что же нам теперь делать? За эти несколько дней, мы начали переделывать систему для нового модуля поиска (возможно еще какие-то другие модули), и что же теперь делать: копировать все это счастье, возвращаться к «примерно последней работающей версии», делать в ней изменения и переделанную прогу отдавать клиентам. А уже потом обратно затирать изменения и возвращаться к нашей новой переделываемой системе.

Да, возвращаться. Только не к "примерно последней рабочей версии", а к "последней версии, отправленной заказчику" — если вы пользуете SS, то вычленить ее трудно, но возможно, если я не ошибаюсь. А на будущее — в SS есть понятия labels и sharing/branching. Так вот при каждой новой поставке заказчику делается label, например "Release_2", после чего начинается работа над новым релизом. Дальше могу ошибаться, но: если заказчик захочет изменить что-то в Release_2, то по метке Release_2 делается branch в Release_2.1, где можно начинать делать фиксы, которые просил заказчик. При этом в основной ветке может параллельно продолжаться работа над следующим релизом. Мержить придется, если, опять же, не ошибаюсь, вручную.