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

22

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

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

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

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

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

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

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

Matt
источник
Похоже, вы уже используете SVN в качестве DVCS (в любом случае, в отношении ветвления). Я уверен, что вы можете сделать почти все, что Mercurial может сделать с SVN (и наоборот); вопрос в том, какой из них проще и удобнее для вашего конкретного сценария развития? Я думаю, вам нужно немного попробовать Mercurial, чтобы убедиться, стоит ли это того или нет
Кэмерон
Я фанат Mercurial, и он явно предлагает расширенный набор функций SVN, но, как говорится, эти дополнительные функции действительно очень полезны для небольшого меньшинства проектов. Возможно, вам это не нужно, это не изменит вашу жизнь, но вы получите больше возможностей и ничего не потеряете, так почему бы и нет?
Джигги,
Вы проверили Hg Init ? Это учебник по Mercurial, написанный Джоэлем Спольски. Он начинается с главы для пользователей Subversion, но в противном случае вы ожидаете, что вы ничего не знаете о DVCS.
Барри Браун

Ответы:

11

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

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

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

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

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

Карл Билефельдт
источник
2
+1! Кроме того, если вы дадите Mercurial честную и тщательную попытку, я уверен, что вы не захотите возвращаться.
Пит
1
«Вы должны спросить себя, что бы вы сделали с тем количеством веток, которое вы хотите, и которые будут доступны всем, кому вы хотите, и только им» ... »- двум людям, работающим на противоположных сторонах интерфейса? Им нужно делиться кодом с каждым другие регулярно, но они еще недостаточно стабильны, чтобы делиться ими со всеми. Они могут создать ветку для совместного использования между собой, а затем слить ее обратно в центральное хранилище, когда она будет готова ». У нас все это теперь с подрывной деятельностью.
Мэтт
@ Матт, тогда тебе повезло, потому что твой бизнес - скорее исключение, чем правило. Большинство компаний имеют очень строгие правила создания филиалов на ограниченном ресурсе центрального сервера, поэтому люди даже не думают о создании их по временным причинам.
Карл Билефельдт
3
Я думаю, что в этом ответе отсутствует тот факт, что оригинальный постер уже заставляет SVN работать таким образом, который намного ближе к рабочему процессу DVCS, чем большинство пользователей SVN сочли бы жизнеспособным. По сути, у них уже есть мышление DVCS, поэтому не требуется никакого фундаментального сдвига в мышлении .
Марк Бут
Хороший вопрос @ Марк. В такой маленькой команде многие обычные соглашения для больших команд выходят за рамки. Я все еще думаю, что оно того стоит по соображениям скорости.
Карл Билефельдт
1

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

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

dfjacobs
источник
Мы хотим потратить время, чтобы измениться? Нет, особенно когда мы перешли на SVN только за последние 2 года. Спасибо за ваши комментарии.
Мэтт
1

Мне кажется, что вы уже используете рабочий процесс, который очень похож на рабочий процесс, который многие люди принимают после того, как они начинают использовать 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.

Марк Бут
источник
1
SVN не выдает конфликт в случае, если вы упомянули. Он появляется только тогда, когда вы оба меняете одни и те же строки. Слияние, как правило, больше связано с переименовыванием / перемещением файлов или добавлением / удалением в svn, потому что оно плохо обрабатывает изменения слияния каталогов. SVN merge дает вам больше возможностей, чем эти 2, обычно я использую «использовать их, а не мои», так как вы обычно хотите сохранить оба набора изменений, а не удалять их оба!
gbjbaanb
@gbjbaanb - это не то, что я обнаружил, поэтому я оценил свой опыт работы с SVN at least the version I've used. Насколько я понимаю, последняя версия svn действительно понимает общих предков, но у меня нет такого опыта, и я подозреваю, что на многих серверах работают более старые версии svn, которые имеют те же проблемы.
Марк Бут
Кстати, мне нравится тот факт, что с hg(и почти наверняка git, но я не пробовал) вы можете взять файл с тремя классами, разбить его на три файла с классом каждый, а затем объединить изменения между веткой с «объединенный» файл и ветвь с отдельными файлами, так что изменения отдельных классов применяются к нужным файлам. Чистая магия. * 8 ')
Марк Бут
1
gbjbaanb правильно; У SVN не будет конфликта в сценарии, который вы описываете. Это довольно легко продемонстрировать себе.
Джереми
@ Джереми @gbjaanb - отредактированный раздел работает лучше для вас? Я не собираюсь спорить с вами о том, как svnдолжны работать слияния, у меня есть собственный опыт работы с ним в svnкомандной строке и SVNKit в Eclipse, где простое получение обновлений может привести к «конфликтам», которые должны быть разрешены вручную с помощью метода «вырезать и вставить». (Я не могу легко сказать: «Я хочу оба этих изменения, в этом порядке).
Марк Бут
0

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

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

SK-логика
источник