Когда и почему вы выбираете централизованный (SVN) распределенный (Git, Mercurial)

Ответ 1

Subversion - очень хорошая централизованная система контроля версий. Он является зрелым и хорошо поддерживается другими инструментами, такими как Trac. Его "одна версия за снимок" выдающаяся, а "ветвь" - просто "световая копия". Действительно, в контексте устаревшего управления версиями с более "хрупкой" семантикой (например, номера версий для каждого файла и их собственными особенностями) Subversion является выдающимся. (Я использовал его в течение многих лет.)

Тем не менее, я переезжаю в Mercurial. (Я бы рассмотрел Git, но Mercurial в настоящее время гораздо более зрелый в Windows.) Tortoise-Hg не так зреет, как Tortoise-SVN. Однако как Mercurial, так и Git являются ПОСТРОЕННЫМИ ДЛЯ СМЕРТИ. И, что основная проблема для систем управления версиями.

В Mercurial у каждого репозитория есть все. Слияния просто. Репозиторий сам по себе является "песочницей", поэтому вам не нужно иметь "ясновидение" "Магистральных" и "ветвей", а также выполнять другое планирование перед филиалом. Короче говоря, распределенные репозитории - это то, как работают команды разработчиков, даже если разработчики централизованы в командной структуре (переходя к ветке "окончательно одобренной магистрали" ).

Сводка: Subversion - отличная модель, но очень централизованная. Он зрелый, со зрелыми инструментами и зрелой интеграцией с другими инструментами (такими как Trac). Mercurial (и Git) являются лучшими моделями, но предоставляют ту же самую "единственную версию за каждый репозиторий-моментальный снимок" как Subversion. Инструменты (например, Tortoise-Hg) менее зрелые (интеграция с Trac - это больше работы), и вы будете думать немного по-другому при работе с Mercurial (например, распределенные репозитории, которые синхронизированы), что дает некоторые преимущества, но вы должны действительно подумайте о проблеме по-другому (чем вы сделали с Subversion).

Я использую как ежедневно. Они оба потрясающие. Когда мы получим интеграцию Mercurial с Trac более зрелым образом, я полностью перейду в Mercurial. (Менее зрелая Черепаха-Hg не так хороша, как Tortoise-Svn, но я могу жить с ней.)

Полная миграция только на Mercurial может занять некоторое время (например, через год или два, поскольку Trac обеспечивает лучшую интеграцию с Mercurial). Импорт/экспорт между Mercurial и Subversion не страшен. Мы используем оба в нашей существующей кодовой базе: Central "trunk" - это Subversion, а локальные изменения в Mercurial, с окончательной регистрацией обратно в Subversion. Он работает.

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

Наконец, в контексте того, как вы сформулировали свой вопрос:

Итак, когда и почему вы выбираете SVN над Mercurial в новом проекте, несмотря на многие преимущества Mercurial/ Gitнад SVN?

Я бы выбрал Svn над Mercurial, потому что:

• Интеграция с другими инструментами (например, Trac) более зрелая, и мы используем эти другие инструменты;
• Утилитный интерфейс (например, Tortoise-Svn) значительно больше зрелые, чем интерфейсы Mercurial (например, Tortoise-Hg);
• Subversion концептуально очень простой модели (например, single-version-snapshot) и централизованное хранилище - это то, как люди исторически думают о версии контроля (разное мышление требуется для распределенного Git/Меркуриальная модель)
• У нас есть твердый процесс, который планирует "багажник" и "ветки", и не требуют значительной поддержки инструмента помочь с этими болезненными сливает-через-ветки.

Ответ 2

Когда меня принуждают к популярному мнению коллег или руководителей по fiat. Это наиболее вероятный сценарий.

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

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

Ответ 3

Одно слово: TortoiseSVN. Для меня TortoiseSVN является стандартом для всех клиентов GUI для любого VCS. Несмотря на недостатки SVN в фронте DVCS, TortoiseSVN делает использование SVN ветерок. TortoiseGit довольно хорош и моделирует TortoiseSVN, но TortoiseHg не так велик.

Еще одна причина - огромная поддержка sysadmin. Инструменты хорошо развиты и зрелы, когда дело доходит до SVN. И Git, и Hg еще не догоняют.

Вы также можете посмотреть мой ответ здесь: какой вариант управления лучше всего подходит для меня?

Также это очень похожий вопрос: https://stackoverflow.com/questions/2693045/mercurial-vs-subversion

Ответ 4

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