Как экспортировать историю изменений из mercurial или git в cvs?

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

создание исходного клона

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

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

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

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

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

Настройки Настроек

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

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

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

Добавочные Импорт

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

% git cvsimport

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

% git cvsimport -r cvs -d $CVSROOT cvs_module_to_checkout

в любом случае, две вещи, чтобы иметь в виду:

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

Внесение Локальных Изменений

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

экспорт изменений в CVS

The git cvsexportcommit команда позволяет экспортировать одну фиксацию на сервер CVS. Вы можете указать один идентификатор фиксации (или все, что описывает конкретную фиксацию, как определено в man git-rev-parse). Затем создается diff, применяется к проверке CVS, а затем (необязательно) фиксируется на CVS с использованием фактического cvs клиент. Вы можете экспортировать каждую микро-фиксацию в своих тематических ветвях, но обычно мне нравится создавать слияние фиксации на актуальном master и экспортируйте эту единственную фиксацию слияния в CVS. Когда вы экспортируете фиксацию слияния, вы должны сказать git, какой фиксатор родителя использовать для создания diff. Кроме того, это не будет работать, если ваше слияние было перемоткой вперед (см. раздел "как работает слияние"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

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

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

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

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

% cvs commit -F .msg file1 file2 file3 etc

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

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

если у вас есть более одного человека, нужно делать cvsimport, было бы более эффективно иметь один репозиторий git, который выполняет cvsimport и имеет все другие репозитории, созданные как клон. Это прекрасно работает, и клонированный репозиторий может выполнять cvsexportcommits так же, как описано выше. Однако есть один нюанс. Из-за того, что коммиты CVS возвращаются с разными идентификаторами фиксации (как описано выше), вы не хотите, чтобы ваша клонированная ветвь отслеживала центральный репозиторий git. По умолчанию, это как 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

---

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