11.10.2011 22:14, Oleksandr Gavenko пишет:
11.10.2011 19:05, Artem Chuprina пишет:
Есть ствол, где идет основная разработка.
очень большой минус SVN в этом случае - куча конфликтов и надо будет
вручную
копипастить изменения. В меркуриале как то все само сращивается молча.
Уже года три-четыре как в SVN извели эту проблему. Там, правда, ключ
определенный надо сказать. В svn-book это описано.
Это про лето 2010 и SVN 1.6 c svn:merge свойством, цепляемым на каталог
после использования команды svn merge?
Вот что примечательно - механизм svn:merge предвосхищает возможности
всех популярных DVCS.
Всем известен механизм cherry-pick или transplant (как вам по душе
угодней называться) и почему это нужно (напомню - для распространения
баг фиксов по веткам).
Что же плохого в cherry-pick? Мы теряем историю мержей! Наши GIT/HG/BZR
базируються на DAG графе, а cherry-pick'ом мы плюем на этот граф.
В идеалах существующей архитектуры DVCS мы должны были бы сделать
следующее:
* bisect'ом найти первую ревизию BADREV, внесшую баг.
* Посмотреть на дерево бранчей и пометить те вершины, в
которых мы заинтересованы в исправлении бага BR1REV, BR2REV.
* Выполнить команду:
$ hg log -r ancestors(BADREV,BR1REV,BR2REV)
$ git-merge-base BADREV BR1REV BR2REV
и исправить баг в полученой ревизии.
Затем мы можем багфикс правоставно смержить (НЕ ЧЕРИПИКИТЬ!!) в
BR1REV, BR2REV, ...
Почему то люди отказываться от указаных шагов и фиксят баг на вершине
истории и распространяют исправление в виде патча с помошью "вишенки"...
C svn:merge "вишенка" была бы "умной", но увы... куча конфликтов
гарантирована при частом обращении к "вишенке".
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j725u7$33f$1...@dough.gmane.org