Вопрс о subversions/client

[uncle_Pasha]

А ручной merge (то что я имел ввиду) навязывается только когда возникают "конфликты"
А они при правильной организации процесса разработки не должны быть.
Так что вы меня не так поняли...

Я вас понял.
Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

Удачи!

[katit]

Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

Ручками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)

[Hamster]

Я вас понял.
Расскажите мне, например, как вы "правильно" организуете процесс в простейшем случае, когда надо обслуживать релиз 1.0 (своевременно выпускать патчи) и заниматься разработкой релиза 2.0.
(Разумеется, баги пофиксенные для релиза 1 не должны появляться опять в релизе 2, а количество патчей исчисляется десятками).

В CVS:
В момент выхода релиза 1.0 создается новый бранч RELEASE_1_0. Основная разработка ведется в HEAD. Обслуживание 1.0 ведется в бранче.
Периодически выполняется команда типа:
cvs update -jRELEASE_1_0:2004/05/01 -jRELEASE_1_0:2004/04/01 modulename

Затем руками исправляются все конфликты.
Работает, если в HEAD не делается таких радикальных изменений, что код в RELEASE_1_0 и HEAD становится не похож друг на друга ( в таком случае, баг придется фиксить два раза, и никакой source control system не поможет ).

[uncle_Pasha]

В CVS:
В момент выхода релиза 1.0 создается новый бранч RELEASE_1_0. Основная разработка ведется в HEAD. Обслуживание 1.0 ведется в бранче.
Периодически выполняется команда типа:
cvs update -jRELEASE_1_0:2004/05/01 -jRELEASE_1_0:2004/04/01 modulename

Затем руками исправляются все конфликты.

И я вам легко нарисую пример, когда один и тот же конфликт надо будет разрешать "ручками" для патча 1, потом 2, потом3, ... N, N+1, ...
В реальной жизни таких точек будут десятки-сотни, что делает работу по мерджеванию в CVS весьма "приятной и интеллектуальной". О которой девелоперы только и мечтать могли...

Удачи!

[uncle_Pasha]

[quote="katitРучками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)[/quote]
Автоматическое создание бранчей для модифицируемых элементов.
Периодический мердж с запоминанием точки мерджа и контрибьюторов (единожды разрешенный конфликт не будет вам предложен еще раз при мердже последующего патча)
Мердж краток и прост, девелопер получает удовольствие и тратит освободившееся время на что-либо более полезное

Удачи!

[Hamster]

И я вам легко нарисую пример, когда один и тот же конфликт надо будет разрешать "ручками" для патча 1, потом 2, потом3, ... N, N+1, ...

Рисуйте.

Автоматическое создание бранчей для модифицируемых элементов

Не понял, что такое модифицируемый элемент? Полномасштабный бранч в момент выпуска версии 1.0 есть или его нет? Если есть, зачем еще что-то автоматически создавать?

Периодический мердж с запоминанием точки мерджа и контрибьюторов (единожды разрешенный конфликт не будет вам предложен еще раз при мердже последующего патча)

В CVS тоже не будет. Недостаток только в том, что нужно помнить ( или записывать ), что патчи вплоть до такой-то даты уже были merged. Автоматически branch merge делать невозможно, потому что в любом merge бывают конфликты, и эти конфликты нельзя разрешать без участия developer'а.

[Strannik223]

[quote="katitРучками. Тот кто пофиксил в 1 пофиксит и в 2.
А как другие системы это делают? (Уменя только опыт с VSS и SVN)

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

Удачи![/quote]

Что то я не понимаю. Создание бранчей, сколько будет изменений столько и бранчей? И как такой лес поможет?

Что такое периодический мерж? Это когда я меньше всего этого ожидаю и хочу, вдруг система мне версию сама похачит, решив что все, пора!?

Как единожды разрешенный конфликт может возникнуть опять?

[uncle_Pasha]

Что то я не понимаю. Создание бранчей, сколько будет изменений столько и бранчей? И как такой лес поможет?

Наример, у вас есть 2 бранча - для фикса релиза 1 и для релиза 2. Они растут из одного места - оригинальный релиз 1.
Если элемент (файл) необходимо модифицировать для фикса - создается бранч этого елемента. Если элемент не модифицировался, используется оригинальная версия без создания бранча. Никакого леса.

Что такое периодический мерж? Это когда я меньше всего этого ожидаю и хочу, вдруг система мне версию сама похачит, решив что все, пора!?

То, о чем вы говорите, возможно, но в данном случае имелось ввиду другое - сформирован рел 1 патч 22 - мердж в рел 2
сформирован рел 1 патч 23 - мердж в рел 2
сформирован рел 1 патч 24 - мердж в рел 2

Как единожды разрешенный конфликт может возникнуть опять?

допустим, некая переменная не была инициализирована и это пофиксено в патче 22:
i = 0;
в релизе 2 кто-то по какой-то несвязанной причине сделал что-то аналогичное:
i = NULL;
Во время мерджа патча 22 в релиз происходит конфликт, который девелопер разрешает в пользу версии из релиза 2 (нравится она ему больше).

Проблема в том, что в случае мерджа следующего патча 23 в релиз 2 тот же конфликт будет предложен для разрешения снова. потом, при патче 24 снова и т.д.

Удачи!

[Hamster]

допустим, некая переменная не была инициализирована и это пофиксено в патче 22:
i = 0;
в релизе 2 кто-то по какой-то несвязанной причине сделал что-то аналогичное:
i = NULL;
Во время мерджа патча 22 в релиз происходит конфликт, который девелопер разрешает в пользу версии из релиза 2 (нравится она ему больше).

Проблема в том, что в случае мерджа следующего патча 23 в релиз 2 тот же конфликт будет предложен для разрешения снова. потом, при патче 24 снова и т.д.

При merge патча 22 в HEAD будет merge'иться diff между версией 1.0 patch 21 и версией 1.0 patch 22. В diff'е будет что-то такое:

+ i = 0;

CVS увидит конфликт и вставит в локальную версию кода:

<<< something.c:1.100
i = NULL;
===
i = 0;
>>> something.c:1.90.2.10


При merge патча 23, соответственно, используется diff между patch 22 и patch 23. В patch 23 эта строчка не меняется. Конфликта не будет.

[uncle_Pasha]

При merge патча 23, соответственно, используется diff между patch 22 и patch 23.

Вот с этого момента поподробнее, пожалуйста...
Каким это волшебным образом CVS начнет использовать diff между вв 22 и 23?
Удачи!

[Hamster]

Вот с этого момента поподробнее, пожалуйста...
Каким это волшебным образом CVS начнет использовать diff между вв 22 и 23?

Читайте тут:
http://cvsbook.red-bean.com/cvsbook.htm ... e%20Merges

[uncle_Pasha]

Вот с этого момента поподробнее, пожалуйста...
Каким это волшебным образом CVS начнет использовать diff между вв 22 и 23?

Читайте тут:
http://cvsbook.red-bean.com/cvsbook.htm ... e%20Merges

Т.е. иными словами, если Вы не помните, что было предыдущей точкой мерджа, то разницу получить не получится. Вы сами выполняете за RCS/CVS/PVCS/VSS работу, которую нормальные системы управления кодом берут на себя.

Удачи!

[Hamster]

Т.е. иными словами, если Вы не помните, что было предыдущей точкой мерджа, то разницу получить не получится. Вы сами выполняете за RCS/CVS/PVCS/VSS работу, которую нормальные системы управления кодом берут на себя.

Совершенно верно.