Mercurial по сравнению с частными филиалами в SVN

Question

Предположим на минуту, что поддержка ветвления / слияния в SVN так же хороша, как и в Mercurial.

Рассмотрим, с одной стороны, систему SVN, где люди всегда работают в своих собственных частных филиалах, а затем, когда они находятся в подходящей точке, объединяют свою частную ветку с «главной» (или с любым другим «родителем»).ветка бывает).Периодически они могут объединяться другим способом, чтобы обновлять свою частную ветку.

Затем, с другой стороны, рассмотрим установку Mercurial с центральным репозиторием, и каждый человек тянет и толкает в / из своего собственного репозитория, в который он вписывает свои обязательства по своему усмотрению.

Таким образом, частная ветвь в SVN соответствует локальному репозиторию в Mercurial, а pull / push в HG соответствует слиянию с частной веткой в ​​SVN.

Разве это не позволяет SVNпо сути, зеркало Mercurial, созданного в этом случае?Какие еще преимущества имеет Mercurial в этом сценарии?

Обратите внимание, что мое вступительное предложение - «предположим на мгновение» - по крайней мере, в той версии SVN, которую мы имеем, - это то, где модель SVN нам не подходит.,Количество слияния, которое оно будет включать, и особенно слияние туда и обратно между основной ветвью и частной ветвью, было бы адским конфликтом.Если бы SVN был так же хорош в отслеживании ветвей и слияний, как Mercurial, решит ли это проблему в SVN?Является ли последний код сервера SVN, поддерживающий отслеживание отслеживания ветвей, для такого рода использования?

Спасибо.

Answer 1

Нет, Subversion по-прежнему не может объединяться так же сильно, как Mercurial. Я привел явный пример того, как Subversion не удается объединить две ветви этот ответ . Нет ничего, что мешало бы централизованной системе хорошо объединяться, просто ветки используются в децентрализованной системе настолько, что она вынуждена хорошо объединяться.

Помимо поддержки слияния, большее преимущество Mercurial перед Subversion заключается в гибкости децентрализованного управления версиями:

• Вы можете сделать много небольших коммитов, а затем выполнить hg rebase --collapse, чтобы объединить их в более крупный и лучший коммит, прежде чем отправлять их в мир.

• Вы можете использовать расширение MQ или расширение rebase для уточнения наборов изменений перед их публикацией.

• Вы можете безопасно совершить коммит, а затем передумать и выбросить вещи с помощью hg strip или более безопасного hg clone -r.

Это позволяет вам экспериментировать более свободно, и в результате Mercurial становится защитной сеткой вместо препятствия. Глубоко иронично, что такие инструменты, как Subversion, оказываются тем, что люди не используют - они не фиксируют свои изменения в течение нескольких дней, потому что боятся сломать сборку, и они не будут использовать ветки, потому что они сожжены ими в прошлом.

Выше были только локальные гибкие возможности - Mercurial также позволяет вам организовывать хорошие потоки наборов изменений между репозиториями: у вас может быть хранилище, в котором привратник выполняет QA и пропускает наборы изменений только после их тестирования. Такая гибкость встроена в децентрализованную модель.

Answer 2

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

В DVCS разработчики могут делать со своим кодом все, что угодно, и по-прежнему делать отправку, поскольку никто не узнает об изменениях до тех пор, пока изменения не будут переданы.Они имеют привилегию экспериментировать, тем самым повышая производительность и эффективность кода, потому что все, что они делают, может быть отменено.