Стоит ли использовать распределенный контроль версий, такой как Mercurial, для команды из одного человека? - PullRequest
4 голосов
/ 15 марта 2010

В настоящее время я использую Subversion для своей компании-разработчика программного обеспечения. Стоит ли переходить на Hg (Mercurial)? Или преимущества возможны только в многопрофильной команде?

Ответы [ 7 ]

9 голосов
/ 15 марта 2010

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

  • hg commit: очень быстро, поэтому вы будете склонны делать более мелкие коммиты, чем с Subversion. Коммит также действительно атомарен в Mercurial, поскольку у нас нет смешанных ревизий . Я считаю это преимуществом, но здесь люди могут не согласиться.
  • hg tag: указывает на конкретную точку в истории, а не на копию под /tags. Проблема с тегами Subversion заключается в том, что копия может совпадать или не совпадать с тем, как /trunk смотрел конкретную ревизию. В Subversion действительно нет встроенных тегов, и, подражая им, можно запутаться так, как это невозможно сделать в Mercurial.

Поскольку Mercurial работает очень быстро, люди используют его не так, как вы бы использовали Subversion. Хорошим примером этого является hg bisect. Вы используете его, чтобы найти первую ревизию, в которой присутствует конкретная ошибка. Это работает с помощью бинарного поиска, где вы сокращаете интервал поиска на каждом шаге. Вы также можете сделать это с Subversion, но встроенной поддержки для него нет, и это будет медленнее, потому что вам нужно связаться с сервером по сети.

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

6 голосов
/ 16 марта 2010

Исходя из моего опыта, Git и Mercurial в настоящее время больше подходят для проектов с открытым исходным кодом или для небольшой команды или команды из одного человека. Так что, в вашем случае, я бы порекомендовал их. Subversion больше подходит для крупных организаций, которым требуется централизованное репо и более детальный контроль доступа.

4 голосов
/ 15 марта 2010

Почти все лучше, чем использование Subversion IMO. Мне нравятся Mercurial (hg) и Darcs, но моим любимым на сегодняшний день остается Fossil для личных проектов (а также для общего доступа). С одним двоичным файлом и одним файлом на каждое хранилище легко отслеживать мою работу, легко создавать резервные копии, легко перемещать ее и т. Д. Кроме того, встроенная вики позволяет мне поддерживать мозговой штурм вместе со своими источниками возможность проверять мою документацию (сгенерированную или иным образом) и получать к ней доступ через встроенный сервер - все мои работы хранятся в одном месте, а встроенный трекер проблем позволяет мне отслеживать историю того, над чем я работал работа в будущем.

О, и Windows не так уж и много, как гражданин второго сорта с Fossil, как с несколькими другими DSCM, которые я могу назвать. (Я смотрю на тебя здесь, Git.)

3 голосов
/ 15 марта 2010

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

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

Когда я впервые переключился на hg, у меня было постоянное чувство "о ... это работает намного лучше, чем svn". На данный момент я бы не рассматривал SVN для себя или для небольшой команды, а только для Mercurial, Git или аналогичных DVCS (хотя я предпочитаю Mercurial)

3 голосов
/ 15 марта 2010

Я настоятельно рекомендую вам прочитать hginit . Это отличный учебник для Hg, и есть вероятность, что после прочтения вы будете проданы: -)

1 голос
/ 15 марта 2010

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

В противном случае я бы просто придерживался Subversion. если они вам нужны, научитесь правильно использовать ветки релизов и функций. для этого нет причин переходить в hg, даже если hginit говорит вам, насколько плоха подрывная деятельность;)

0 голосов
/ 24 марта 2010

Я бы определенно рекомендовал использовать контроль версий для индивидуальной разработки. Не имеет большого значения, какой вы используете, SVN, Git, Hg и т. Д. Причина в том, что он позволяет выполнять откат в случае регрессивной ошибки, потери кода, повреждения и, конечно, возможностей ветвления и объединения ( вы всегда должны развиваться в ветке и объединяться с транком только тогда, когда новая функция / ошибка полностью протестирована) и т. д. Все эти вещи (и даже больше) вы не сможете использовать без системы контроля версий.

...