Причины предпочтения CVS над SVN или Git [закрыто]

Я только что нашел проект с открытым исходным кодом, который все еще использует CVS. Я задавался вопросом, есть ли еще какие-то причины предпочесть CVS SVN или Git в настоящее время. (Я не считаю, что слишком ленив, чтобы мигрировать в качестве ответа! ; -))

есть ли у CVS что-нибудь, чего не хватает двум другим? Скажем, поддержка $OS или $fancy_tool?

в "каковы преимущества использования SVN над CVS? " есть подробные ответы, почему не использовать CVS. Но я хочу спросить наоборот. CVS не может быть все плохо. Или нет?

4 ответов


Я все еще использую CVS для некоторых своих личных вещей.

в отличие от Git, вы можете легко проверить только подмножество хранилища.

и CVS присваивает последовательные номера версий (1.1, 1.2, 1.3,...) к каждому файлу. В Git номера версий представляют собой 40-символьные шестнадцатеричные контрольные суммы. В SVN номера ревизий являются последовательными по всему репозиторию; заданное число применяется ко всему репозиторию.

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

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

(этого не произойдет, если репозиторий содержит исходные файлы используется для создания одной программы или библиотеки; в этом случае вам нужна согласованная история для проекта в целом.)

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

обновление: этот вопрос нарисовал пару необъяснимых минусами. Я могу только догадываться о причинах (и я не беспокоюсь о случайном downvote), но, возможно, некоторые читатели думают, что я защищаю CVS как лучшую систему, чем SVN или Git. Я просто указываю, что CVS может иметь некоторые преимущества в некоторых довольно узких обстоятельствах.


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

это похоже на вопрос, как MS-DOS превосходит Windows в качестве операционной системы. Я мог бы придумать какие-нибудь фальшивые причины ("хорошо... ...э... MS-DOS требует меньше памяти."). Но, в в конце концов, Windows была написана, чтобы позаботиться о коротких приходах MS-DOS.

некоторые причины, по которым CVS лучше подрывать, просто не выдерживают, как только вы понимаете рассуждения:

  • в CVS теги и ветви были двумя совершенно разными понятиями. На самом деле, не было большой разницы между биркой или веткой. В CVS ,v файл, ветви и теги были сглажены до определенных изменений в начале файла. Фактически, вы использовали ту же команду: cvs tag для создания ветви или тега. Это одна из причин, почему Subversion не проводила различия между этими двумя понятиями. Однако, обрабатывая ветви и теги одинаково, Subversion дала вам возможность отслеживать историю ветви или тега. Кто его создал и когда? На каком пересмотре он основан? Это изменилось? Subversion также дает вам простой способ увидеть все теги или ветви в вашем репозитории. В CVS, вы должны пройти через каждый файл.
  • CVS больше гибкий, чем Subversion, потому что Subversion более или менее заставляет вас работать во всех каталогах. В CVS вы можете проверить туда и сюда, внести свои изменения, а затем пометить их все сразу. Конечно, это действительно плохой, ужасный, ужасный, опасный способ работы. Что обычно происходит, так это то, что вам говорят сделать сборку на основе старого тега, но затем поместите эти полдюжины или около того изменений файла. Затем создайте новый тег. Веселье и волнение происходят, когда вы пытаетесь следовать этим направлениям. Сделали ли вы новый тег в редакции 1.3.4.2.3.2.5.2 или 1.3.2.4.3.2.5.2?
  • CVS позволяет иметь разреженные метки и ветвления. Вы можете иметь базовый тег, а затем добавить другие теги поверх этого. Конечно, причина, по которой большинство сайтов сделали это, заключается в том, что для ветвления или тегирования действительно большого репозитория CVS может потребоваться несколько часов. Subversion делает то же самое за микросекунду.
  • CVS использует стандартный формат файла RCS, поэтому вы можете исправить проблемы в своем репозитории. Однако большую часть времени, ты создаешь больше проблем, чем исправляешь.

CVS было большим улучшением по сравнению с RCS. В CVS вам не нужно было блокировать файл перед его изменением. В CVS вы можете проверять целые поддеревья без написания какого-либо системного интерфейса. RCS был разработан для версии отдельных файлов. Резюме версионный весь репозиторий как единый проект.

сам RCS был улучшением по сравнению с SCCS. Формат репозитория RCS был проще понять. Расширение сайта работал лучше и был менее загадочным. У вас могут быть ветви ветвей, в то время как SCCS оставил вам только один уровень ветви. У RCS была встроенная концепция тегов, в то время как SCCS требовал, чтобы вы отслеживали теги самостоятельно.

и SCCS было намного лучше, чем вообще не использовать исходный репозиторий.

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


единственное, с чем я столкнулся в моем ограниченном использовании CVS, это то, что CVS рассматривает ветви и теги как разные, а также рассматривает их как то, что они есть, а не как просто папки, которые делает SVN. Для них существуют специальные команды, и они рассматриваются как граждане первого класса системы управления версиями. Как создать филиал в SVN? svn copy. Тэг? тот же. В чем разница? Ничего, кроме того, как с ними обращаться. Хотя можно сказать, что модель SVN приводит к простоте, она заставляет различные инструменты неправильно понимать их и не получать контекст папок. Если вы видите Git, он похож на CVS таким образом.

но, безусловно, нет причин использовать CVS now-a-days, кроме устаревших причин. Многие говорят, что SVN был построен, чтобы быть лучшим CVS и почти во всех аспектах SVN лучше и широко используется.


CVS, git и subversion имеют разные конструкции рабочих процессов. Это неточно и вводит в заблуждение (git/subversion был разработан для устранения проблем с cvs). Скорее, subversion была написана, потому что кто-то хотел другой рабочий процесс, чем CVS/RCS работает лучше всего. И тогда git был написан, потому что кто-то хотел еще один рабочий процесс.

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