Аргументы, чтобы убедить перейти с CVS на SVN

Question

Отдел UNIX моей компании в настоящее время использует CVS в качестве системы контроля версий исходного кода. Они используют его очень странным образом : разные хранилища для кода разработки / тестирования / производства (для одного и того же проекта), никто ничего не помечает, странная архитектура каталогов и т. Д.

Система была установлена ​​на века, но теперь у меня есть возможность организовать встречу, где я должен предложить изменения. Я бы хотел изменить их с CVS на SVN (Mercurial или Git могут быть даже лучше, однако я не могу порекомендовать использовать систему, которую я плохо знаю, и переход на SVN уже станет большим шагом вперед).

У меня нет большого опыта работы с CVS, поэтому я не могу их эффективно сравнить: я просто знаю, что он не поддерживает атомарные операции и что устарел .

Какие убийственные аргументы вы бы использовали, чтобы убедить моих коллег сделать это?

Большое спасибо.

Answer 1

Хм, эта настройка звучит как распределенная VCS, поэтому Mercurial или Git могут очень хорошо соответствовать. Multi-repository-setup является особенностью этого. Я лично предпочитаю Subversion, но в вашем случае вам стоит взглянуть на них, hginit может быть хорошим введением в Mercurial.

В любом случае, аргументы для переключения:

• атомные коммиты
• улучшенная обработка бинарных файлов
• контроль версий каталогов (только SVN)
• свойства файлов и каталогов (только SVN)

Answer 2

На самом деле атомные коммиты являются нарушителем, а не какой-то вкусной особенностью. Например, вы хотите зафиксировать 50 измененных файлов. С SVN вы svn commit, и случается, что сеть терпит неудачу в середине коммита - ваш коммит будет проигнорирован. С CVS у вас будет половина коммита в репозитории, так что теперь все обновятся до неработающего кода и станут несчастными, а ежедневная сборка может дать сбой и сделать всех еще более несчастными. С svn вы либо успешно завершили коммит, либо похоже, что вы никогда не коммитировали - репозиторий всегда исправен.

Answer 3

Вопрос в том, какие конкретные проблемы возникают при текущей настройке CVS? Ваши причины для изменения должны устранить их. Но если они не испытывают каких-либо проблем, изменение ради изменений не является хорошей идеей - CVS фактически сделает эту работу во многих случаях. И если они старые UNIX-парни, они, вероятно, помнят некоторые действительно ужасные системы контроля версий из прошлого, и думают, что CVS довольно аккуратный!

Answer 4

Если честно, если вам придется усердно трудиться, чтобы убедить их, то они, скорее всего, ожидают, что он потерпит неудачу (даже если только подсознательно), и ваши усилия могут быть лучше потрачены в другом месте.

Я бы начал использовать hg, git или другую DVCS локально (фиксируя репозитории CVS отдела), чтобы вы могли с ними ознакомиться. Благодаря их распределенному характеру, вы можете сами начать осознавать преимущества, начать показывать преимущества коллегам индивидуально и, в конечном итоге, убедительно обосновать необходимость конверсии, опираясь на реальный опыт ваших проектов.

Answer 5

Переименование / перемещение файлов! В целом, я сомневаюсь, что это убедительная причина для перехода, но это имело серьезные последствия для проекта, в котором я когда-то был.

Смотрите, CVS не позволяет вам переименовывать / перемещать файлы. Если вы переименуете или переместите файл, CVS считает, что старый один исчез, а новый появился, и что между ними нет никакой связи. Несмотря на отсутствие реальной истории изменений, вы должны знать, что «Файл X» на самом деле был «Файл Y», если вы вернетесь к какой-то определенной дате. Да, и номера версий сбрасываются.

Проект, над которым я работал, был Java-приложением с открытым исходным кодом, которое только начинало с малого, росло и росло, так что все было просто в пакете «core. *». Когда пришло время пересмотреть и поместить вещи в хорошую иерархию пакетов ... ну, CVS сбросил всю информацию о версии, потому что, насколько знал он , мы просто удалили все "ядро" / "и создал кучу новых файлов из воздуха.

Предположительно, SVN осведомлен о файлах, перемещаемых / переименованных, поэтому он не нарушает происхождение версий. Не знаю, делает ли это Git.