Я использовал SVN и CVS немного, но мне нужно будет выбрать один для нового проекта, который я начну.
Может ли кто-нибудь, кто использовал оба экстенсивно, предлагать некоторые плюсы и минусы и которые, по их мнению, лучше? Также будут оценены лучшие учебные ресурсы.
Это будет для небольшого проекта, для начала нужно создать только один или два разработчика.
Я использовал оба. Нет никакого сравнения; вы хотите svn. Единственная причина использования CVS заключается в том, что вы вводите или применяете устаревшую систему с управлением, которое не хочет изменять статус-кво. Если вы начинаете новый проект, практически логично не утверждать, что CVS лучше, чем Subversion.
Если вы google вокруг, вы должны найти множество сравнений и обоснований для использования Subversion над CVS. Некоторые из преимуществ Subversion над CVS:
Сказав все это, я рекомендую вам также изучить некоторые распространенные VCS, такие как Bazaar, Mercurial и git. Я лично использую git для всех моих проектов.
Subversion имеет некоторые существенные победы над CVS:
Однако он имеет серьезные недостатки. Самым большим является то, что ветки и теги не являются гражданами первого класса в svn, это просто каталоги, которые придерживаются конвенции. В дополнение к потере некоторых преимуществ реального разветвления и тегирования (упомянутых в других комментариях) самая большая проблема, которую он создает, заключается в том, что если очень легко завинчиваться.
Использование Subversion в соглашении, а не в конфигурации означает, что вам нужно заранее подумать о своей структуре репозиториев и обеспечить, чтобы все придерживались этого. Кроме того, вы создаете мир обид для будущих поколений, не говоря уже о каких-либо инструментах, которые нужно пережить ваше репо.
Слияние и зеркалирование были почти несуществующими (помощь для) до 1.5. 1.5 предпринял шаги для решения этих проблем, но есть еще возможности для улучшения. Слияние в подрывной деятельности все еще намного сложнее, чем должно быть.
SVN над CVS почти не вызывает затруднений. Тем не менее, вы не должны, по крайней мере, подумать о том, что может предложить DVCS (Git, Hg, Bzr), или если ваш бюджет позволяет использовать коммерческие инструменты с отличной репутацией (Accurev, Perforce).
Subversion, вероятно, правильный выбор, но вы должны сделать домашнее задание, чтобы получить наилучшие результаты. Начните с Красной книги http://svnbook.red-bean.com/
Хотя я бы выбрал Subversion над CVS в большинстве случаев, вы должны знать, чего не хватает в Subversion:
CVS видит теги и ветки как разные вещи; Subversion нет. Это означает, что сторонние инструменты, созданные поверх Subversion (например, IDE с интеграцией управления версиями), имеют более сложную работу, зная разницу. Обычно вам нужно сделать какую-то специальную конфигурацию, чтобы сообщить, где находятся ваши теги и ветки, и вы должны убедиться, что ваши пользователи придерживаются определенного расположения файловой системы.
Subversion не может посмотреть файл и сообщить вам, в какой момент кто-то создал ветку или тег. Такие инструменты, как CVSGraph, могут использовать эту информацию для рисования дерева истории файлов. Чтобы сделать это с помощью Subversion, вам нужно будет искать все каталоги ветвей/тегов, и я не видел каких-либо инструментов, которые хорошо это делают.
CVS работает дольше, а сторонние инструменты более стабильны, по моему опыту.
Назовите меня старомодным, но я предпочитал модель ветвления/маркировки под CVS.
В CVS ветки и теги - разные вещи. Тег - это метка для пересмотра. Они очень полезны для таких вещей, как маркировка тега PRODUCTTION для синхронизации файлов с вашим сервером. Вам не нужно сливаться, чтобы обновлять файлы ПРОДУКТА - вы просто перемещаете тег.
Филиалы живут в одном и том же "пространстве имен" в качестве основного файла - легко отследить все моды конкретного файла.
В SVN нет таких вещей, как тег. Там только ветки. Если вам нужны теги, вам нужно создать ветку и притвориться ее тегом. Филиалы - это в основном копии файлов. В прошлый раз, когда я использовал SVN для ветвей/слияний, вам приходилось записывать ревизию предварительно разветвленного файла, если вы когда-либо надеялись объединить его вместе (заметьте, я не эксперт SVN, поэтому это может измениться).
Считая, что SVN лучше во всех отношениях, и вы, вероятно, не должны начинать новый проект с помощью CVS.
Ты собираешься получить много ответов на это, я подозреваю. Они могут даже согласиться.
Между этими двумя вариантами, я считаю, что нет сомнений в том, что вы должны использовать Subversion. Subversion была построена как "лучшее CVS", и в результате никто больше не поддерживает CVS. Subversion имеет возможность переименовывать и перемещать файлы без потери истории, поддерживает атомарные коммиты, имеет более надежный формат репозитория, имеет более современные методы доступа, имеет лучшую поддержку сторонних инструментов и список продолжается.
Subversion похожа на "лучший CVS". Он отлично управляет файлами файлов AND. Он имеет поддержку ветвления, хотя он уступает распределенным VCS.
Вы также можете рассмотреть возможность использования распределенного VCS, такого как git, базар или меркурий.
Изменить: Вот ссылка на аналогичный вопрос
Как правило, Subversion. Однако вы должны следить за проблемами ресурсов.
Когда я работал в игровой компании, у нас было несколько каталогов, содержащих сотни крошечных файлов и других каталогов, содержащих несколько сотен мега файлов. Когда мы перешли с CVS на Subversion, скорость проверки репо уменьшилась с одного часа до четырех или пяти часов. Обновление также было существенно медленным.
Это почти наверняка связано с использованием либо http, либо ssh для передачи данных файла по сравнению с родным CSV-сервером, однако, поскольку так легко настроить svn поверх ssh или webdav, люди, как правило, не думают о накладных расходах протокола. Однако вы можете использовать собственный протокол svn, и это должно облегчить проблему, мы не тестировали это в моей старой компании.
Другой проблемой, которая часто игнорируется, является пространство для хранения, мы обнаружили, что подрывная деятельность использовала в несколько раз больше места хранения, чем CVS. Я, кажется, помню, что он хранит локальную копию данных репо, чтобы ускорить работу, это не будет большой проблемой, если вы не сохраните несколько гигабайт в своем репозитории.
Я использовал subversion в течение 3,5 лет, теперь я переехал в другую компанию, которая использует CVS для контроля версий. Во-первых, между ними не так много различий, но приступая к операции слияния (что является главной частью моих проблем), я мог бы сказать, что CVS сделал лучшую работу. Понятия ветвей/тегов в SVN сбивают с толку, хотя в CVS очень ясно. также слияние (в моем случае, интеграция ветки) намного проще в CVS, чем в SVN. Слабость CVS до сих пор в моей идее - только атомная фиксация. в противном случае это был бы хороший выбор.