Когда и почему вы выберете централизованное (SVN), а не распределенное (Git, Mercurial) - PullRequest
11 голосов
/ 14 мая 2011

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

Учитывая, что большинство статей в Интернетео объяснении, почему выбирают Mercurial вместо SVN (или что-то подобное).Я хотел бы спросить обратное.

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

Ответы [ 4 ]

11 голосов
/ 14 мая 2011

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

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

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

10 голосов
/ 14 мая 2011

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

Тем не менее, я переезжаю в Mercurial. (Я бы рассмотрел Git, но в настоящее время Mercurial гораздо более зрелый в Windows.) Tortoise-Hg далеко не так зрел, как Tortoise-SVN. Тем не менее, и Mercurial, и Git созданы для слияния. И это фундаментальная проблема для систем контроля версий.

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

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

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

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

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

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

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

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

  1. Интеграция с другими инструментами (например, Trac) более зрелый, и мы используем эти другие инструменты;
  2. Интерфейс утилиты (например, Черепаха-Свн) значительно больше более зрелые, чем Mercurial (как черепаха-Hg);
  3. Subversion концептуально очень простая модель (например, единственная версия-снимок), и централизованное хранилище, как люди исторически думать о версии контроль (другое мышление требуется для распределенного Git / Mercurial модель)
  4. У нас есть надежный процесс, который планирует «ствол» и «ветки», а не требуется значительная поддержка инструмента для помочь с этими болезненными сливает-по-ветви.
2 голосов
/ 14 мая 2011

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

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

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

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

0 голосов
/ 14 мая 2011

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

...