Есть ли какой-нибудь разумный способ перейти с Subversion на CVS?

Question

Моя компания невольно перешла с cvs на subversion, и теперь мы все хотим вернуть cvs. Я знаю, что есть инструменты для переноса истории и изменений с cvs на svn, и нет эквивалента для обратного. Любые предложения или идеи, как это сделать?

Answer 1

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

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

Я также считаю, что вы действительно ничего не получите, переключившись обратно на CVS, но если вы захотите это сделать, то, скорее всего, вы будете писать собственный сценарий. Команда "svn export", несомненно, будет полезна в этом начинании.

Answer 2

Так что же с SVN, что вашей компании так не нравится, а CVS работает лучше? Разработчики SVN старались изо всех сил сделать SVN-интерфейс достаточно похожим на CVS. Если вы используете клиент Tortoise в качестве внешнего интерфейса, опыт будет очень похожим. SVN дает вам атомарные коммиты, которые, хотя и не совсем соответствуют стандарту Perforce, находятся в нескольких милях от CVS.

Я должен сочувствовать твоему положению. Я обновил нашу команду разработчиков и команду ИТ с CVS до SVN. У меня есть все необходимые скрипты Python для обновления всей истории версий, и мы счастливо используем SVN уже почти 4 года. Около трех месяцев назад руководитель IT-группы решил «обновить» все свои проекты из SVN, чтобы догадаться, что? Правильно, тяжеловес систем контроля версий: SourceSafe!

Я бы определенно остановился на SVN или даже посмотрел бы на некоторые из более новых распределенных систем, таких как Mercurial. С этими системами нет центрального сервера. Они полагаются на способность разветвляться и объединяться между десятками или сотнями пиров. Вы определяете свою собственную топологию, поэтому, например, вы бы указали, что конкретный одноранговый узел выполняет ежедневные сборки.

Answer 3

Я не думаю, что инструменты существуют для того, чтобы идти в другом направлении, потому что на них не так много спроса.

Если вы действительно должны это сделать, не составит труда написать сценарий, который просматривает историю репозитория SVN, получает каждую ревизию и фиксирует ее в CVS.

Кстати, мне искренне интересно узнать, какие у вас проблемы с SVN.

Answer 4

Один аспект git не обсуждался, когда он был представлен вашему вниманию во всех остальных ответах: git предоставляет эмуляцию сервера cvs, так что вы можете перейти на git (svn to git легко и хорошо поддерживается) и позже используйте серверный интерфейс cvs для централизованного доступа к хранилищу. Никто не должен знать, что вы используете git в фоновом режиме, и вам не нужно иметь дело с проблемами распределенного резервного копирования.

Answer 5

SVN не велик. SVN лучше, чем CVS. Если вы хотите изменить кассу Mercurial, GIT, Bazaar.

Answer 6

Не обновление. Не делай этого.

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

Если по какой-либо причине вам нужно что-то кроме SVN, посмотрите на другие системы контроля версий. Их много, и они почти все лучше, чем CVS (фактически, только Visual Source Safe настолько плох).

Answer 7

Ваши возможности, вероятно, действительно ограничены. Помните, что активная разработка CVS прекратилась некоторое время назад, поэтому, вероятно, для вас нет инструментов от разработчиков CVS. И поскольку одной из основных целей svn было улучшение CVS, эти разработчики, вероятно, не ожидали, что кто-то будет двигаться назад.

Но если вам не нравится subversion, почему бы не взглянуть на более современные распределенные системы (git, mercurial и т. Д.)?

Answer 8

SVN должен был быть лучше, чем CVS, но в некоторых областях, которые не работали хорошо. Другие распределенные инструменты работают намного быстрее (svn, черт возьми, медленен, иногда даже cvs может быть быстрее), имеют гораздо больше полезных функций, чем svn, быстро развиваются (хотя просмотр любой новой функции в svn занимает ГОДЫ) С другой стороны, svn довольно прост в изучении и централизации (это важно для некоторых людей).

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

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

Answer 9

Согласен с капралом Touchy.

SVN лучше, чем CVS, потому что он был спроектирован так: примерно то же самое, с некоторыми упрощениями и новыми функциями.

С помощью Svn вы можете перемещать / переименовывать файл, не теряя его историю; вы получаете более безопасные коммиты (коммиты являются атомарными операциями) и глобальные ревизии.

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

PS: Я думаю, что капрал говорил о Mercurial

Answer 10

когда у вас есть только молоток, все выглядит как гвоздь.

Лучше всего научиться SVN, это сделает более осведомленным.