Аргументы для убеждения для переключения от CVS до SVN
Отдел UNIX моей компании в настоящее время использует CVS в качестве системы управления исходной версии. Они используют его очень странным способом: различные репозитории для кода разработки/тестирования/производства (для того же проекта), никто не отмечает ничего, странной архитектуры каталога, и так далее.
Система была установлена целую вечность, но теперь, у меня есть возможность организовать встречу, где я должен предложить изменения. Я хотел бы заставить их измениться от CVS до SVN (Подвижный, или Мерзавец мог бы быть еще лучше, однако я не могу действительно повторно управлять использованием системы, которую я не знаю хорошо, и переключающийся на SVN уже будет большой шаг вперед).
У меня нет большого опыта с CVS, таким образом, я не могу сравнить их эффективно: Я просто знаю, что это не поддерживает атомарные операции и что это удерживается от использования.
Какие уничтожающие аргументы Вы использовали бы, чтобы убедить моих коллег делать переключатель?
Большое спасибо.
4 ответа
Хм, эта установка звучит как распределенная VCS, так что Mercurial или Git могут очень хорошо подойти. Их особенностью является установка нескольких хранилищ. Я лично предпочитаю Subversion, но в вашем случае вам стоит взглянуть на это, hginit может быть хорошим введением в Mercurial.
В любом случае, аргументы в пользу перехода:
- атомарные коммиты
- лучшая обработка бинарных файлов
- контроль версий каталогов (только SVN)
- свойства файлов и каталогов (только SVN)
На самом деле атомарные коммиты - это нарушение сделки, а не какая-то вкусная особенность. Например, вы хотите зафиксировать 50 измененных файлов. С SVN вы svn commit и случается, что сеть дает сбой в середине фиксации - ваша фиксация будет проигнорирована. С CVS у вас будет половина коммита в репозитории, так что теперь все будут обновляться до битого кода и станут недовольны, а ежедневная сборка может потерпеть неудачу и сделать всех еще более несчастными. С svn у вас либо успешная фиксация, либо похоже, что вы никогда не задумывались о фиксации - репозиторий всегда цел.
Если честно, если вам придется много работать, чтобы убедить их, то они, вероятно, будут ожидать, что это потерпит неудачу (пусть даже подсознательно), а ваши усилие может быть лучше потрачено в другом месте.
Я бы начал использовать hg, git или другую DVCS локально (фиксируя репозитории CVS отдела), чтобы вы могли с ними ознакомиться. Благодаря их распределенной природе, вы можете начать осознавать преимущества самостоятельно, начать показывать преимущества коллегам индивидуально и, в конечном итоге, убедительно обосновать необходимость конверсии, опираясь на реальный опыт ваших проектов.
Вопрос в том, какие конкретные проблемы возникают с текущей установкой CVS? Ваши причины для изменений должны быть направлены именно на них. Но если они не испытывают никаких проблем, изменение ради изменения не является хорошей идеей - CVS действительно справится с работой во многих случаях. А если это ребята из старых UNIX, то они, вероятно, помнят некоторые из действительно ужасных систем контроля версий прошлого и считают, что CVS - это очень здорово!