Как экспортировать историю пересмотра из подвижного или мерзавца к cvs?

К счастью, для тех из нас, кто все еще вынужден использовать CVS, мерзавец обеспечивает довольно хорошие инструменты, чтобы сделать точно, что Вы желаете сделать. Мои предложения (и что мы делаем здесь на уровне $work):

Создание Начального Клона

Использование git cvsimport для клонирования истории пересмотра CVS в репозиторий мерзавца. Я использую следующий вызов:

% git cvsimport -d $CVSROOT -C dir_to_create -r cvs -k \
  -A /path/to/authors/file cvs_module_to_checkout

-A опция является дополнительной, но она помогает сделать Вашу историю пересмотра, это импортируется из более подобного мерзавцу взгляда CVS (см. man git-cvsimport для большего количества информации о том, как это настраивается).

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

, Как только этот процесс завершается, Вы будете иметь master ответвление, которое должно отразить ГОЛОВУ CVS (за исключением того, что git cvsimport по умолчанию игнорирует ценность прошлых 10 минут фиксаций, чтобы не ловить фиксацию, которая наполовину закончена). Можно тогда использовать git log и друзья для исследования всей истории репозитория так же, как если бы это использовало мерзавца с начала.

Тонкие настройки Конфигурации

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

% git config cvsimport.module cvs_module_to_checkout
% git config cvsimport.r cvs
% git config cvsimport.d $CVSROOT

Все эти опции могут быть определены на командной строке, таким образом, Вы могли безопасно пропустить этот шаг.

Возрастающий Импорт

Последующий git cvsimport должен быть намного быстрее, чем первый вызов. Это действительно, однако, делает cvs rlog на каждом каталоге (даже те, которые имеют только файлы в [1 118]), таким образом, может все еще потребоваться несколько минут. Если Вы определили предложенные конфигурации выше, все, что необходимо сделать, выполнитесь:

% git cvsimport

, Если Вы не настроили свои конфигурации для определения значений по умолчанию, необходимо будет определить их на командной строке:

% git cvsimport -r cvs -d $CVSROOT cvs_module_to_checkout

Так или иначе, две вещи иметь в виду:

1. Удостоверяются, что Вы находитесь в корневом каталоге Вашего репозитория мерзавца. Если Вы еще будете везде, то это попытается сделать новое cvsimport, который снова возьмет навсегда.
2. Удостоверяются, что Вы находитесь на Вашем master ответвление так, чтобы изменения могли быть объединены (или перебазирующимися) в Ваши локальные ответвления / ответвления темы.

Вносящие Локальные Изменения

На практике, я рекомендую всегда внести изменения на ответвлениях и только объединиться с [1 121], когда Вы готовы экспортировать, они возвращаются в репозиторий CVS. Можно использовать любой рабочий процесс, который Вы любите на своих ответвлениях (слияние, перебазирование, сплющивание, и т.д.), но конечно стандартные правила перебазирования применяются: не повторно базируйтесь, если кто-либо еще основывал их изменения на Вашем ответвлении.

Изменения Экспорта в CVS

Эти git cvsexportcommit управляют, позволяет Вам экспортировать выбрать фиксацию в сервер CVS. Можно определить единственный идентификатор фиксации (или что-либо, что описывает определенную фиксацию, как определено в [1 135] man git-rev-parse ). Разность тогда сгенерирована, относится контроль CVS и затем (дополнительно) предана CVS с помощью фактического cvs клиент. Вы могли экспортировать каждую микро фиксацию на своих ответвлениях темы, но обычно мне нравится создавать фиксацию слияния на актуальном master и экспорт, что единственное слияние соглашается на CVS. При экспорте фиксации слияния необходимо сказать мерзавцу, которые передают родителя для использования для генерации различного. Кроме того, это не будет работать, если Ваше слияние было ускоренной перемоткой вперед (см. раздел "HOW MERGE WORKS" [1 136] man git-merge для описания слияния ускоренной перемотки вперед), таким образом, необходимо использовать --no-ff опция при выполнении слияния. Вот пример:

# on master
% git merge --no-ff --log -m "Optional commit message here" topic/branch/name
% git cvsexportcommit -w /path/to/cvs/checkout -u -p -c ORIG_HEAD HEAD

Вы видите то, что каждую из тех опций означают на страница справочника для мерзавца-cvsexportcommit . У Вас действительно есть опция установки -w опция в Вашей конфигурации мерзавца:

% git config cvsexportcommit.cvsdir /path/to/cvs/checkout

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

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

% cvs commit -F .msg file1 file2 file3 etc

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

Клонирование Вашего клона CVS

, Если бы у Вас есть больше чем один человек, бывший должный сделать эти cvsimport, было бы более эффективно иметь единственный репозиторий мерзавца, который выполняет cvsimport, и создайте все другие репозитории как клон. Это работает отлично, и клонированный репозиторий может выполнить cvsexportcommits, столь же описанный выше. Существует один протест, как бы то ни было. Из-за пути фиксации CVS возвращаются через с различными идентификаторами фиксации (как описано выше), Вы не хотите, чтобы Ваше клонированное ответвление отследило центральный репозиторий мерзавца. По умолчанию это - то, как git clone настраивает Ваш репозиторий, но это легко исправлено:

% git clone [CENTRAL_REPO_HERE]
% cd [NEW_GIT_REPO_DIR_HERE]
% git config --unset branch.master.remote
% git config --unset branch.master.merge

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

% git pull origin master

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