Subversion vs CVS [закрыто]


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

может ли кто-нибудь, кто широко использовал оба варианта, предложить некоторые плюсы и минусы, и что они считают лучше? Лучшие учебные ресурсы также будут оценены.

Это будет для небольшого проекта, только один или два разработчика, чтобы начать.

8   51   2008-10-29 02:44:21

8 ответов:

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

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

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

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

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

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

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

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

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

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, ветви и теги разные вещи. Тег-это метка для ревизии. Они очень полезны для таких вещей, как маркировка производства тег для файлы для синхронизации с вашим веб-сервером. Вам не нужно объединяться, чтобы обновить производства файлы -- вы просто переместите метку.

ветви живут в том же "пространстве имен", что и основной файл -- это легко отследить все моды конкретного файла.

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

Это, как говорится, Я думаю, SVN лучше во всех других отношениях и, возможно, не стоит начинать новый проект с CVS.

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

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

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

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

Edit: вот это ссылка на аналогичный вопрос

Вообще Подрывная Деятельность .. Однако вы должны следить за ресурсов.

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

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

еще одна проблема, которая часто игнорируется, - это место для хранения, мы обнаружили, что subversion действительно использует в несколько раз больше места для хранения локально, чем CVS. Я, кажется, помню, что он хранит локальную копию РЕПО данные для ускорения дифференциации, это не будет большой проблемой, если вы не храните несколько гигабайт в репозитории.

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