Сравнение Subversion и Mercurial (HG)

[maksbotan]

А почему решили переходить на Git? :) В нём гораздо больше неочевидных моментов (см. этот пост). Мне кажется для новичков в DVCS освоить hg проще.
P.S. хотя сам люблю git =)

[mig35]

Я согласен, что не очевидных моментов у Git больше, но, как я и писал в статье, в компании часть сотрудников уже пользовалась Git (малая, но все же). И просто не решились вводить в интеграцию с существующими сервисами еще одну систему контроля версий.

[UncleAndy]

Работал и с svn и с hg и с git (сейчас на нем). По совокупности впечатлений, конечно hg и git существенно выигрывают у svn. Но у каждого из них есть свои особенности. И я не стал-бы сравнивать hg и git на предмет лучше/хуже.

[mig35]

Вы же сами говорите, что в целом децентрализованные системы контроля версий выигрывают у svn (централизованной системы) при условии, что над проектом работает не менее двух человек, либо этот проект быстро развивается или включен в другой проект. И статья была именно об этом. Не понимаю при чем тут сравнение git и hg.

[UncleAndy]

Да я не возражаю. Просто высказался для тех комментирующих, которые удивляются на счет вашего перехода на git после изучения mercurial. У меня та-же история, вот я и объясняю. :)

[weirdan]

Единственным выходом будет искать ревизию, с которой этот проект работал, и копипастить библиотеки.

В svn:externals есть возможность указать конкретную ревизию. Да и ссылаться в svn:externals нужно на соответвующий релиз-тег библиотеки, а не на транк.

Стоит напомнить то, как ветки реализованы в svn. Это просто папки с полной копией репозитория. Начиная с версии 1.5 появилась история таких файлов, однако все же это просто папки и файлы. Для работы с ними нужно придерживаться специальных правил именования и содержания.

Какие правила вы тут имеете в виду?

Напоследок хочется сказать про историю коммитов. Если в svn она чисто прямолинейная и невозможно сказать, что вы на самом деле основывались на ревизии 2, а не 10 и понятия не имел о том, что происходит с 3 по 10, хотя ваш коммит следует под номером 11…

… то это видно при выполнении svn log --stop-on-copy в бранче. Если бранч создавался как svn cp ^/trunk ^/branches/branchName, то ответвление произошло от ^/trunk@[branch revision — 1], где branch revision — последняя запись в выводе svn log --stop-on-copy (хотя ревизия [branch revision — 1] могла быть совершена не в транке, но ^/trunk@[branch revision — 1] указывает на вполне конкретное состояние транка).

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

Либо вы берете одну из неиспользуемых рабочих копий (которые образовываются в результате «заново выкачивать все сорци с последней ревизии») и делает svn switch / svn up в ней.

[mig35]

В svn:externals есть возможность указать конкретную ревизию. Да и ссылаться в svn:externals нужно на соответвующий релиз-тег библиотеки, а не на транк.

Я не знаю как, но я обошел это стороной… А ведь было введено еще в версии 1.5!
И про tags я тут не написал очень зря…

Какие правила вы тут имеете в виду?

Правила именования папок проекта. trunk — для основной ветви разработки, tags — для состоявшихся релизов и branch для новых фич, которые не нужны пока что в основной ветви.

… то это видно при выполнении svn log --stop-on-copy в бранче. Если бранч создавался как svn cp ^/trunk ^/branches/branchName, то ответвление произошло от ^/trunk@[branch revision — 1], где branch revision — последняя запись в выводе svn log --stop-on-copy (хотя ревизия [branch revision — 1] могла быть совершена не в транке, но ^/trunk@[branch revision — 1] указывает на вполне конкретное состояние транка).

С этим я согласен, но пункт был не про branch, а про обычную разработку. То есть вы обновились и начали что-то делать. При этом у вас ревизия была 2, а когда вы захотели закоммититься, то получилось так, что этот коммит оказался под номером 11. И все выглядит так, что при коммите вы основывались на версии 10, а не на 2ой. И это уже никак восстановить нельзя.

Либо вы берете одну из неиспользуемых рабочих копий (которые образовываются в результате «заново выкачивать все сорци с последней ревизии») и делает svn switch / svn up в ней.

Если я правильно понимаю, то вы тут говорите о ситуации, когда программист находится в branch и переключается обратно в trunk. Однако, я имел в виду то, что он и так уже находится в trunk и просто работает, когда к нему приходят. Хотя, возможно, я не верно понял…

Спасибо большое за замечания. Некоторые вещи не знал и рад, что вы о них сказали =)

[weirdan]

Я не знаю как, но я обошел это стороной… А ведь было введено еще в версии 1.5!

В версии 1.1, если быть точным: svnbook.red-bean.com/en/1.1/ch07s04.html

Правила именования папок проекта. trunk — для основной ветви разработки, tags — для состоявшихся релизов и branch для новых фич, которые не нужны пока что в основной ветви.

Это лишь соглашение по именованию. Как вы сами правильно отметили, svn — это всего лишь папки и файлы, так что можно придумать и другую структуру.

С этим я согласен, но пункт был не про branch, а про обычную разработку.

Но бранч — это и есть обычная разработка :)
Впрочем, понятно, вы имели в виду мерджи в пределах одного бранча. Это довольно редкая для меня ситуация, поскольку мы ведем всю разработку в feature branches, и обычно в бранч коммитит только один разработчик.

Если я правильно понимаю, то вы тут говорите о ситуации, когда программист находится в branch и переключается обратно в trunk.

Ну так это не суть важно. Для subversion нет особой разницы между бранчами, тегами и транком — это всего лишь папки (связаные отношением наследования, но все равно лишь папки). Так что где-бы разработчик не работал, он просто переключается в/создает другой тег/бранч/транк и делает то, что у него попросили.

[rg_software]

Мне кажется, выбор системы обусловлен большим количеством факторов, чем просто «два человека работают над проектом или двадцать».

Децентрализованные системы хранят все ревизии у каждого участника?.. Если так, то представьте, что разрабатывается видеоигра или что-нибудь в этом роде, и в проекте присутствуют многомега- и даже гигабайтные файлы с графикой и музыкой, постоянно обновляемые. Этого ни один обычный компьютер разработчика не выдержит.

Лично мне психологически проще работать с SVN. Ну просто потому что как-то чётче процесс поставлен: вот сервер, здесь все ревизии, бэкапы, здесь же «мастер-версия» проекта, последняя гарантированная ревизия.