Мы фанаты Subversion и хотим узнать о преимуществах Mercurial [закрыто]

Прочитав, что я выродок Subversion, почему я должен рассмотреть или не рассмотреть Mercurial или Git или любой другой DVCS .

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

Наша команда состоит из 8-10 разработчиков, которые работают над одной большой кодовой базой, состоящей из 60 проектов. Мы используем Subversion и имеем основной ствол. Когда разработчик запускает новое дело Fogbugz, он создает ветку svn, выполняет работу над веткой, и когда они это делают, они объединяются обратно в ствол. Иногда они могут оставаться на ветке в течение продолжительного времени и объединять ствол с веткой, чтобы получить изменения.

Когда я смотрел, как Линус говорит о людях, создающих ветку и никогда не делающих этого снова, это совсем не мы. Мы создаем около 50-100 веток в неделю без проблем. Самая большая проблема - это слияние, но мы также неплохо справились с этим. Я склонен сливаться с помощью fogbugz case & checkin, а не со всем корнем ветви.

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

После создания ветки следующая проверка 60k + файлов занимает некоторое время, но это будет проблемой для любой системы контроля версий, которую мы будем использовать.

Есть ли какая-то польза от какой-либо DVCS, которую мы не видим, которая бы нам очень помогла?

Перефразируя ваш вопрос: «Если мы планируем использовать DVCS только централизованно, какие преимущества он имеет?» Когда вы спрашиваете так, это не так. Одна ветвь на задачу чрезвычайно распространена в VCS. Если подумать, то наличие локальной рабочей копии исходного кода на машине разработчика, которая меняется независимо от транка за день, - это ветвь, хотя никто так не называет это. Единственная разница между этим и вашим рабочим процессом заключается в том, что вы также даете этим веткам постоянное имя на центральном сервере. Это не та ветвь, о которой говорят Линус и другие.

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

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

Способность выполнять промежуточные локальные коммиты стоит того сама. Это то, что вы просто должны испытать на себе.

Скорость, полученная благодаря локальному репо, тоже стоит того. Да, первоначальное клонирование будет неизбежно медленным в любой VCS для репозитория 60 КБ, но как только вы это сделаете, проверка новой ветви на несколько порядков быстрее с DVCS.

В вашем конкретном случае переход на DVCS бесполезен. Вы довольны своей существующей системой, она делает все, что вам нужно, так зачем переключаться? SVN по-прежнему является активным проектом с открытым исходным кодом и имеет лучшую, более зрелую интеграцию со всеми основными IDE и инструментами разработки, чем hg или git. Учитывая размер вашей команды и количество проектов, вы действительно хотите потратить время на то, чтобы перейти на новый инструмент, когда существующий работает нормально?

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

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

С вашей точки зрения, DVCS будет иметь следующие существенные преимущества перед SVN:

• После того, как вы клонировали свои репозитории, многие операции могут выполняться локально.
  • Просмотр журнала репозитория не должен касаться сервера SVN, поэтому может быть невероятно быстрым.
  • Точно так же, переключение филиалов не требует доступа к серверу и локальных клонов.
• Поскольку ветви - это просто разные пути в истории, ваш репозиторий не загроможден каждой веткой, которую каждый создал каждый (у нас действительно есть только ветки релизов в SVN, но в branchesкаталоге все еще есть много подкаталогов, которые больше не актуальны).
  • В git, после того как ветка была объединена и ссылка удалена, вы никогда не узнаете, что она там была.
  • В Mercurial у вас есть выбор: либо назвать ветвь (в этом случае она постоянно закодирована в каждом наборе изменений), либо просто создать неназванную (топологическую) ветвь, которая будет тихо сливаться с историей, когда она mergeвозвращается в default( trunk)
• В SVN ветви филиалов слишком неясны, чтобы быть полезными. В gitи hgони просто в порядке вещей.
• DVCS понимают, что разработка программного обеспечения - это группа обеспечения доступности баз данных , т. Е. При слиянии вы получаете набор изменений с несколькими родителями. SVN (по крайней мере, версия, которую я использовал) на самом деле не понимает этого.

На последнем пункте вы говорите

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

При переходе от использования hgисключительно с использованием в svnодиночку , а затем gitsvnон был мой опыт , что слияния являются гораздо проще и без проблем бесплатно hgи gitsvnчем они с svn. Сливается сsvn (по крайней мере, версией, которую мы используем) приводят к значительно большему количеству конфликтов, которые необходимо разрешать вручную.

Одна из причин, по которой слияния сложнее в SVN, заключается в том, что он дает вам только два варианта для каждой линии, которая отличается,

• текст из ветви, в которую вы сливаете
• текст из ветви, в которую вы сливаетесь

в то время как слияния из DVCS обычно дают вам третий вариант, который

• текст от общего предка обеих веток, который вы объединяете

Не стоит недооценивать, насколько это полезно, это дает вам много лучший контекст для изменений, чем простой двухсторонний diff.

В общем, я бы посоветовал вам попробовать. С такими инструментами, как gitsvnи hgsubversion, вы даже можете опробовать их в своих текущих репозиториях SVN .

^{Обратите внимание, что создание клона в первую очередь - это королевская PItA, но как только вы это сделаете, вы получите большую часть возможностей DVCS с вашей существующей CVCS.}

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

Но на самом деле я на самом деле не отошел от Subversion. Я просто использую Git в качестве локального клиента SVN.