Subversion против CVS

Subversion похожа на "лучшую CVS". Он хорошо справляется с перемещением файлов и каталогов. У него есть поддержка ветвления, хотя она уступает распределенным VCS.

Вы также можете рассмотреть возможность использования распределенной VCS, такой как git, bazaar или mercurial.

Обновлено: вот ссылка на аналогичный вопрос

Я подозреваю, что вы получите много ответов на этот вопрос. Они могут даже согласиться.

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

Я использовал оба. Нет никакого сравнения; вы хотите svn. Единственная причина использовать CVS заключается в том, что вы входите в унаследованную систему или принимаете ее, а руководство не хочет менять статус-кво. Если вы начинаете новый проект, практически невозможно утверждать, что CVS лучше Subversion.

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

• может легко перемещать или переименовывать файлы или каталоги
• атомарные коммиты
• "дешевое" копирование и разветвление
• коммиты - это наборы изменений для всего дерева (а не только истории отдельных файлов)

Сказав все это, я рекомендую вам также изучить некоторые из распределенных VCS, таких как Bazaar, Mercurial и git. Я лично использую git во всех своих проектах.

Назовите меня старомодным, но я предпочел модель ветвления / тегирования в CVS.

В CVS ветки и теги разные вещи. Тег - это метка для ревизии. Они очень полезны для таких вещей, как маркировка тега ПРОИЗВОДСТВО для файлов, которые нужно синхронизировать с вашим веб-сервером. Вам не нужно выполнять слияние, чтобы обновить файлы ПРОИЗВОДСТВО - вы просто перемещаете тег.

Ветви находятся в том же «пространстве имен», что и основной файл - легко отследить все моды конкретного файла.

В SVN нет тега. Есть только ветки. Если вам нужны теги, вам нужно создать ветку и сделать вид, что это тег. Филиалы - это в основном копии файлов. В прошлый раз, когда я использовал SVN для ветвей / слияний, вам нужно было записать ревизию предварительно разветвленного файла, если вы когда-либо надеялись объединить его вместе (обратите внимание, я не эксперт по SVN, поэтому это могло измениться).

При этом я думаю, что SVN лучше во всех остальных отношениях, и вам, вероятно, не стоит начинать новый проект с CVS.

Хотя в большинстве случаев я бы предпочел Subversion CVS, вы должны знать, чего вам не хватает в Subversion:

• CVS рассматривает теги и ветки как разные вещи; Subversion - нет. Это означает, что сторонним инструментам, созданным на основе Subversion (например, IDE с интеграцией системы управления версиями), труднее понять разницу. Обычно вам нужно выполнить некоторую специальную конфигурацию, чтобы указать ему, где находятся ваши теги и ветки, и вы должны убедиться, что ваши пользователи придерживаются определенного макета файловой системы.

• Subversion не может взглянуть на файл и сказать вам, в какой момент кто-то создал из него ветку или тег. Такие инструменты, как CVSGraph, могут использовать эту информацию для построения дерева истории файла. Чтобы сделать это с помощью Subversion, вам нужно будет выполнить поиск во всех каталогах веток / тегов, и я не видел ни одного инструмента, который бы делал это хорошо.

• CVS существует дольше, а сторонние инструменты, по моему опыту, более стабильны.

Subversion имеет несколько существенных преимуществ над CVS:

1. хорошие удаленные параметры http / https / svn vs pserver
2. атомарные коммиты
3. повсеместная поддержка инструментов
4. переименовать
5. управление версиями каталогов

Однако у него есть серьезные недостатки. Самым большим, безусловно, является то, что ветви и теги не являются первоклассными гражданами в svn, это просто каталоги, которые придерживаются соглашения. Помимо потери некоторых преимуществ реального ветвления и тегирования (упомянутых в других комментариях), самая большая проблема, которую он создает, заключается в том, что if позволяет очень легко облажаться.

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

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

SVN поверх CVS почти не вызывает затруднений. Однако было бы упущением не подумать хотя бы о том, что могут предложить DVCS (Git, Hg, Bzr) или, если ваш бюджет позволяет, существуют коммерческие инструменты с отличной репутацией (Accurev, Perforce).

Subversion, вероятно, является правильным выбором, но вы должны сделать свою домашнюю работу, чтобы получить наилучшие результаты. Начать с Красной книги http://svnbook.red-bean.com/

Обычно Subversion .. Однако вам следует остерегаться проблем с ресурсами.

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

Это почти наверняка связано с использованием http или ssh для передачи файловых данных по сравнению с собственным csv pserver, однако, поскольку svn очень легко настроить поверх ssh или webdav, люди, как правило, не думают о накладных расходах протокола. Однако вы можете использовать собственный протокол svn, и это должно решить проблему, мы не тестировали это в моей старой компании.

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

Я использую Subversion 3,5 года, теперь я перешел в другую компанию, которая использует CVS для управления версиями. Поначалу между ними не так много различий, но, переходя к операции слияния (что является главной из моих проблем), я могу сказать, что CVS справилась лучше. Концепции ветвей / тегов в SVN сбивают с толку, но очень понятны в CVS. также слияние (в моем случае интеграция ветки) намного проще в CVS, чем в SVN. Слабость CVS пока в моем представлении только атомарная фиксация. в противном случае это был бы хороший выбор.