Моя компания невольно перешла с cvs на Subversion, и теперь мы все желаем, чтобы у нас снова не было cvs. Я знаю, что есть инструменты для переноса истории и изменений с cvs на svn, и нет эквивалента для обратного. Есть предложения или идеи о том, как это сделать?
Есть ли разумный способ перейти с Subversion на CVS?
Ответы (13)
Изначально я добавил это как комментарий к чьему-то ответу, но потом понял, что это своего рода ответ. Я делал подобные переходы раньше, когда не существовало способа перехода от одной системы SCM к другой.
Это не ракетостроение - писать скрипт, который берет список коммитов из вашего репозитория SVN и выполняет итерацию по ним по очереди, объединяя их во вновь созданный репозиторий CVS. Получение точных значений всех ветвей и тегов может потребовать немного больше усилий, но если вы хотите просто сохранить историю изменений для нескольких веток, это должно быть довольно легко.
Я также считаю, что вы ничего не получите, вернувшись к CVS, но если вы захотите это сделать, то, скорее всего, вы напишете свой собственный сценарий. Команда "svn export", несомненно, будет полезна в этом деле.
Так что же в SVN, что ваша компания так не любит, а CVS лучше? Разработчики SVN изо всех сил старались сделать работу с SVN похожей на CVS. Если вы используете клиент Tortoise в качестве внешнего интерфейса, опыт будет очень похожим. SVN дает вам атомарные коммиты, которые, хотя и не совсем соответствуют стандарту Perforce, намного опережают CVS.
Я должен посочувствовать твоему положению. Я повысил уровень нашей команды разработчиков и ИТ-специалистов с CVS до SVN. У меня есть все нужные скрипты Python для обновления всей истории версий, и мы успешно используем SVN почти 4 года. Около трех месяцев назад руководитель ИТ-команды решил «обновить» все свои проекты с SVN, чтобы угадайте, что? Правильно, тяжеловес систем контроля версий: SourceSafe!
Я бы определенно остановился на SVN или даже посмотрел на некоторые из более новых распределенных систем, таких как Mercurial. В этих системах нет центрального сервера. Они полагаются на возможность ветвления и слияния десятков или сотен пиров. Вы определяете свою собственную топологию, поэтому, например, вы должны указать конкретный одноранговый узел как тот, который выполняет ежедневные сборки.
Я не думаю, что существуют инструменты, позволяющие двигаться в другом направлении, потому что на них нет большого спроса.
Если вы действительно должны это сделать, не составит большого труда написать сценарий, который просматривает историю репозитория SVN, получает каждую ревизию и фиксирует ее в CVS.
Кстати, мне искренне интересно узнать, какие у вас проблемы с SVN.
SVN не очень хорош. SVN лучше CVS. Если вы хотите сменить кассу Mercurial, GIT, Bazaar.
Один аспект git не обсуждался, когда он был доведен до вашего сведения во всех этих других ответах: git обеспечивает эмуляцию сервера cvs, чтобы вы могли перейти на git (svn на git прост и хорошо поддерживается), а затем использовать cvs-серверный интерфейс для централизованного доступа к репозиторию. Никто не должен знать, что вы используете git в фоновом режиме, и вам не нужно иметь дело с проблемами распределенного резервного копирования.
Не апгрейд. Не делайте этого.
Серьезно, почему вы предпочли бы CVS SVN? CVS - это буквально игрушка, которая делает вид, что позволяет командам работать без явного общения. Это действительно ужасно.
Если вам по какой-либо причине нужно что-то другое, кроме SVN, посмотрите другие системы контроля версий. Их много, и почти все они лучше, чем CVS (на самом деле, только Visual Source Safe так плохо).
Ваши возможности, вероятно, действительно ограничены. Помните, что активная разработка CVS некоторое время назад прекратилась, поэтому, вероятно, для вас нет инструментов от разработчиков CVS. А поскольку одной из основных целей svn было улучшение CVS, эти разработчики, вероятно, не ожидали, что кто-то пойдет назад.
Но если вам не нравится подрывная деятельность, почему бы не взглянуть на более современные распределенные системы (git, mercurial и т. Д.)?
когда все, что у вас есть, это молоток, все выглядит как гвоздь.
Лучше всего выучить svn, это сделает более знающими.
Согласитесь с капралом Обидчивым.
SVN лучше, чем CVS, потому что он был разработан для этого - это примерно то же самое, с некоторыми упрощениями и новыми функциями.
С помощью Svn вы можете перемещать / переименовывать файл без потери его истории; вы получаете более безопасные коммиты (коммиты - это атомарные операции) и глобальные изменения.
В любом случае, постарайтесь лучше узнать его, прежде чем вернуться к CVS, и, что еще лучше, постарайтесь по-настоящему понять ваши потребности как команды для репозитория.
PS: Я думаю, капрал имел в виду Mercurial
Предполагалось, что svn лучше, чем cvs, но в некоторых областях это не сработало. Другие распределенные инструменты намного быстрее (svn чертовски медленен, даже cvs иногда может быть быстрее), имеют гораздо больше полезных функций, чем svn, быстро развиваются (хотя просмотр любой новой функции в svn занимает ГОДЫ). С другой стороны, svn довольно прост в изучении и централизован (для некоторых это важно).
Команда svn сосредоточена на собственной повестке дня, очень сложно получить поддержку от разработчиков (по сравнению с другими проектами с открытым исходным кодом), некоторые отчеты об ошибках существуют в течение длительного времени без какого-либо интереса со стороны разработчиков.
Я разочарован тем, как выглядит проект svn и как он развивается, но что ж, может быть, это изменится в будущем.
единственные 2 недостатка Subversion, которые я могу придумать для пользователей, пришедших из CVS:
- скорость оформления заказа через http (s)
- отсутствие модулялинов
первый может быть решен с помощью svn (+ ssh), который является более сопоставимым форматом, поскольку CVS также использует свой собственный протокол. второй вариант немного сложнее, но его можно эмулировать с помощью svn: externals (у которого есть свои неприятные побочные эффекты). Если вы столкнулись с какими-либо другими дополнительными недостатками, я все слышу ..
Просто обратите внимание на один момент: Bazzar, Mercurial и т. Д. (Которые были здесь советованы некоторыми людьми) - все это распределенные системы контроля версий. Я обнаружил, что с помощью таких инструментов почти невозможно управлять большими группами программистов, работающих над одним и тем же исходным кодом. В моей компании мы используем SVN, и он отлично справляется со своей задачей.
Понятия не имею, зачем вам это нужно, но переход от SVN -> GIT -> CVS может работать
Вы бы сбежали ..
git svn clone http://thesvnserver ourrepo
Затем используйте следующее руководство для экспорта обратно в CVS (не совсем уверен, что это сработает):
http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html.
git cvsexportcommit 4a20cbafdf25a141b31a8333284a332d1a4d6072
Также есть git cvsserver