Вы бы мигрировали из cvs в svn или напрямую в git или hg?

Question

Я не знаю, правильный ли это форум, чтобы спрашивать.

Моя компания использует CVS в качестве системы контроля версий. Мы планируем перейти на более современную систему контроля версий. Что бы вы посоветовали в качестве наименее рискованного решения?

Моя идея - использовать Subversion, но я также слышу много хорошего о Git и Mercurial

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

Answer 1

Мы мигрировали из CVS в Mercurial около 2 недель назад на моей работе. Мы небольшая команда из 6 человек. Только двое уже работали с чем-то еще, кроме CVS, до миграции.

Я отвечал за выбор нового vcs. Я считал Git и Mercurial.

Некоторые проблемы, которые у нас были с CVS, были плохие возможности ветвления, отсутствие поддержки переименования, действительно плохой алгоритм для конфликтов.

Я никогда не рассматривал SVN, потому что каждый раз, когда я пытался использовать его с ветвями в прошлом, слияния всегда были головной болью. И, честно говоря, в наши дни вся шумиха касается dvcs, и на это должна быть причина;)

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

Преимущества Git / Mercurial над SVN

1. Улучшенные ветки и возможности слияния (действительно самая важная причина)
2. Возможности экспорта / импорта патча в пачках, по электронной почте и т. Д.
3. Не проводил обширных тестов по этому поводу, но я думаю, что оба быстрее во многих отношениях, чем SVN (слияние, клонирование, диффузия и т. Д.)
4. Разработка намного активнее, я слышал, что команда SVN пытается двигаться вперед, но все же.
5. Действительно хорошая инфраструктура расширений
6. Возможности поставляемого веб-сервера, действительно полезные для быстрого обмена информацией, например.

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

Кривая обучения

Два человека в команде не очень-то обрадовались переменам. Но с небольшим двухчасовым объяснением для всей команды с некоторыми слайдами все прошло гладко.

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

Я думаю, что могу сказать, что примерно через 2 недели каждая из них, по крайней мере, так же продуктивна, как и раньше, и уверена в новом инструменте. И теперь мы можем использовать ветки функций, не опасаясь грядущего слияния:)

Миграция CVS в Mercurial

https://www.mercurial -scm.org / вики / RepositoryConversion # CVS

В официальной вики перечислены различные способы перехода с CVS на Mercurial. Я протестировал расширение Convert и cvs2hg, который наконец-то был использован.

Расширение Tailor, hg-cvs-import, fromcvs похоже на старый код и больше не поддерживается.

Расширение Convert прекрасно работает в простом репозитории, но, поскольку наш CVS-репозиторий был действительно большим и имел несколько действительно странных веток, расширение не смогло правильно импортировать всю историю. ГОЛОВА была правильной, но некоторые ветви отсутствовали.

Итак, последний выбор - cvs2hg . Фактически это новый бэкэнд для cvs2svn, который конвертируется в Mercurial вместо Subersion.

Подход «Быстрый старт», представленный в файле Readme, разработан из коробки со всеми ответвлениями. Но, в конце концов, я использовал файл опций, чтобы добавить некоторые пользовательские сопоставления и удалить некоторые ошибочные коммиты или нежелательные ветки.

Файл опций в прилагаемых файлах хорошо прокомментирован, вам не составит труда настроить его так, как вам удобно.

Для информации, после первоначального преобразования я использовал расширение Convert для некоторого извлечения подпроекта из результирующего репозитория Mercurial в другой репозиторий Mercurial, как объяснено здесь .

Answer 2

Редактировать: Великолепная ссылка - http://whygitisbetterthanx.com/

===============================================================

Да, фактически мы только что перешли из SVN в Mercurial.

В сторонуС распределенной стороны, Mercurial и GIT работают намного быстрее, чем SVN, а также в репо нет раздражающих папок .SVN в любой папке.Не говоря уже о том, что слияние работает лучше!То, что yuo также может хранить ваше хранилище на любом общем диске, - это хорошо (в любом случае, для Mercurial не нужно устанавливать что-либо на сервере)

Подробнее

Должен ли я использовать SVN илиGit?

http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of-revision-control/

http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/

http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/

И, наконец, GIT Vs Mercurial

http://gitvsmercurial.com/ - Этот сайт выглядит как мертвый: (* ​​1029 *

Answer 3

1. Слияние кода и разрешение конфликтов легче использовать распределенную VCS как GIT или Mercurial. Причина это то, что GIT или Mercurial есть все промежуточные снимки два "конечных кода" должны быть объединены Subversion будет знать только конец снимок, если каждый пользователь SVN не работает в своем филиале.

2. С распределенной VCS вы не зависит от сети, чтобы проверить код в.

3. Если у вас большое количество пользователей проверять вещи в VCS ежедневно основа, ваш сервер SVN лучше быть очень мощный для обработки одновременно чек-входы / выходы. У DVCS такой проблемы нет.

Мы перешли с CVS на SVN, а теперь и на Mercurial, и мы очень довольны переходом. В SVN нет ничего, что нам не хватает в Mercurial, но возвращаться в SVN было бы больно.

Answer 4

Вещи SVN, которые могут быть важны для вашего рабочего процесса:

1. Частичные проверки.
   Можно просто оформить часть дерева (важно, если в вашем хранилище более 1 проекта)

2. Смешанные заказы.
   Части вашей проверки могут быть в разных редакциях, вплоть до одного файла.

3. Глобально уникальная ревизия монотонно увеличивается.
   В SVN легко увидеть, что rev 1206 позже 1100 (ср. Cfbb0827c67d позже d500c208c3c5?)

4. Многие проекты могут использовать один и тот же SVN-репозиторий.
   Если ваш пакет состоит из нескольких EXE-файлов, DLL-файлов и еще много чего, на земле Hg / Git вы можете использовать несколько репозиториев для управления этим. Это может несколько усложнить обработку тегов / ревизий

Answer 5

Мы (карты Nokia OVI) также мигрируем из SVN в HG. Причиной выбора HG вместо git является то, что HG более удобен для пользователя, команды имеют гораздо больший смысл по сравнению с иногда непонятными командами git. Также для пользователей Windows Mercurial работает гораздо лучше, а TortoiseHG вполне зрелый. Когда я тестировал git на windows, я обнаружил серьезные проблемы с производительностью при некоторых простых операциях, таких как проверка изменений ...

Мне также очень нравится, что вы можете использовать функции, которые вы хотите через расширения. Таким образом, кривая обучения более плавная, чем с git, рассмотрим, например, область кэша. Для людей из SVN я думаю, что HG - хороший вариант.

Они должны быть более осторожны с историей, например, мы призываем сделать hg pull --rebase, чтобы история была как можно более линейной и объединяла только ветви.