Миграция с CVS на Git без потери истории

Ответ 1

Я лично не делал конверсии из CVS в Git, но я считаю, что Eric Raymond cvs-fast-export - это инструмент для использования, У него есть страница с руководством пользователя здесь. cvsps - еще один инструмент, поддерживаемый Эриком, но недавно он устарел в пользу cvs-fast-export. cvs2git - еще один инструмент, который построен на некоторых тех же машинах, что и cvs2svn. Последний был очень искусным, и поэтому я возлагаю большие надежды на то, что cvs2git одинаково хорош.

Одна вещь, которую нужно отметить: CVS - довольно сломанный RCS. Возможно, он может иметь контент, который не может быть точно отражен в Git. IOW, там есть некоторый импеданс несоответствия, но инструменты очень стараются сохранить как можно больше. Не забудьте проверить ваше преобразование и что вы довольны результатами. Возможно, вам понадобится зафиксировать часть истории Git, чтобы получить что-то более приемлемое, но я сомневаюсь, что вам нужно будет.

Ответ 2

Вот процесс, который я использовал для переноса репозитория SourceForge CVS в Git с использованием cvs2git (последний стабильный выпуск уже здесь, но IIRC я использовал версию github dev), который работает как в Windows, так и в Linux без какой-либо компиляции, так как это всего лишь Python:

Как импортировать CVS из sourceforge в git.
Во-первых, вам нужно скачать/оформить репозиторий cvs со всей историей (не только извлекать HEAD/Trunk):

rsync -av rsync://PROJECT.cvs.sourceforge.net/cvsroot/PROJECT/\* cvs  

затем используйте cvs2git (скрипт Python, работает на всех платформах, компиляция не требуется):

python cvs2git --blobfile="blob.dat" --dumpfile="dump.dat" --username="username_to_access_repo" --options=cvs2git.options --fallback-encoding utf-8 cvs  

это должно было сгенерировать два файла blob и dump, содержащие всю вашу историю cvs. Вы можете открыть их в текстовом редакторе, чтобы проверить правильность содержимого.

затем инициализируйте ваш git-репо в другой папке:

mkdir gitexport/
cd gitexport
git init  

затем загрузите экспортированную историю cvs в git:

cat ../{blob,dump}.dat | git fast-import  

и затем поместите курсор git commit в конец истории:

git reset --hard  

наконец и опционально, вы можете отправить в свой удаленный репозиторий git:

git push -u origin master  

конечно, вам нужно, прежде чем git remote add origin https://your_repo_url

Примечание: cvs2git.options - это файл конфигурации в формате JSON для cvs2git где вы можете указать преобразования для различных вещей, таких как имена авторов (так что их псевдонимы будут автоматически преобразованы в их полное имя после импорта). Смотрите документацию здесь или включенный пример файла опций.

Также вам не нужно владеть репо с помощью этого метода, вы можете переносить проекты SourceForge, которые вам не принадлежат (вам просто нужно иметь право на выкуп, так что это работает в любом публичном репо).

Ответ 3

Вы можете использовать git-cvsimport, чтобы импортировать репозиторий CVS в Git. По умолчанию это проверит каждую ревизию, предоставив вам относительно полную историю.

В зависимости от вашей операционной системы вам может потребоваться установка поддержки для этого отдельно. Например, на машине Ubuntu вам понадобится пакет git-cvs.

Этот ответ более подробно.

Ответ 4

Я использовал недавно (2016) reposurgeon Эрика Раймонда, чтобы импортировать репозиторий CVS из sourceforge в git. Я был очень приятно удивлен и работал очень хорошо. После прошлых опытов с cvs2svn и другими инструментами я рекомендую без задержек повторно выполнить такие задачи.

Эрик опубликовал прямое руководство по миграции здесь

Ответ 5

Чтобы клонировать проект из sourceforge в github, я выполнил следующие шаги.

PROJECT=some_sourceforge_project_name
GITUSER=rubo77
rsync -av rsync://a.cvs.sourceforge.net/cvsroot/$PROJECT/\* cvs
svn export --username=guest http://cvs2svn.tigris.org/svn/cvs2svn/trunk cvs2svn-trunk
cp ./cvs2svn-trunk/cvs2git-example.options ./cvs2git.options
vim cvs2git.options # edit run_options.set_project
cvs2svn-trunk/cvs2git --options=cvs2git.options --fallback-encoding utf-8

создайте пустой git по адресу https://github.com/$GITUSER/$PROJECT.git

git clone [email protected]:$GITUSER/$PROJECT.git $PROJECT-github
cd $PROJECT-github
cat ../cvs2git-tmp/git-{blob,dump}.dat | git fast-import
git log
git reset --hard
git push

Ответ 6

gaborous answer использует git fast-import, что может привести к сбою в сообщении журнала, не закодированном в UTF-8.

Это будет работать лучше с Git 2.23 (Q2 2019): пара " git fast-export/import " научена обрабатывать коммиты с сообщениями журнала в кодировке, отличной от UTF-8.

См. Коммит e80001f, коммит 57a8be2, коммит ccbfc96, коммит 3edfcc6, коммит 32615ce (14 мая 2019 г.) Элайджи Ньюрена (newren).
^{(Объединено Юнио К Хамано - gitster - в коммите 66dc7b6, 13 июня 2019 г.)}

fast-export: делать автоматическое перекодирование сообщений коммита только по запросу

Автоматическое перекодирование сообщений коммита (и удаление заголовка кодирования) затрудняет попытки сделать обратимые переписывания истории (например, переходы sha1sum <-> sha256sum, некоторые перезаписи поддерева) и кажется несовместимым с общим принципом, используемым в других местах fast-export требующие явных пользовательских запросов для изменения вывода (например, --signed-tags=strip, --tag-of-filtered-object=rewrite).
Добавьте флаг --reencode который пользователь может использовать для указания, и, как и другие флаги быстрого экспорта, по умолчанию установите его как " abort ".

Это означает, что Documentation/git-fast-export теперь включает в себя:

 --reencode=(yes|no|abort)::

Укажите, как обрабатывать заголовок encoding в объектах фиксации.

• При запросе " abort " (по умолчанию) эта программа умрет при обнаружении такого объекта фиксации.
• При "да" сообщение о фиксации будет перекодировано в UTF-8.
• При "нет" исходная кодировка будет сохранена.

fast-export: избегайте удаления заголовка кодировки, если мы не можем перекодировать

Когда fast-export встречает коммит с заголовком "кодировка", он пытается перекодировать в UTF-8, а затем отбрасывает заголовок кодирования.
Тем не менее, если он не сможет перекодировать в UTF-8, потому что, например, один из символов в сообщении коммита был недопустим в старой кодировке, тогда нам нужно сохранить исходную кодировку, иначе мы потеряем информацию, необходимую для понимания всех остальных (допустимо). символы в исходном сообщении коммита.

fast-import: поддержка заголовка коммита 'encoding'

Поскольку git поддерживает сообщения о коммитах с кодировкой, отличной от UTF-8, разрешите fast-import для импорта таких коммитов.
Это может быть полезно для людей, которые не хотят перекодировать сообщения фиксации из внешней системы, а также может быть полезно для достижения обратимых переписываний истории (например, переходы sha1sum <-> sha256sum или работа с поддеревьями) с репозиториями Git, которые использовали специализированные кодировки в их история совершения.

Documentation/git-fast-import теперь включает в себя:

кодирование"

Необязательная команда encoding указывает кодировку сообщения фиксации.
Большинство коммитов - UTF-8, и кодировка опущена, но это позволяет импортировать сообщения коммитов в git без их предварительного перекодирования.

Чтобы увидеть тест, который использует автора с не-ascii символами в имени, но без специального сообщения коммита.
Он проверяет, что перекодирование в UTF-8 работает, проверяя его размер:

Объект фиксации, если не перекодирован, будет иметь размер 240 байт.

• При encoding iso-8859-7\n заголовка " encoding iso-8859-7\n " отбрасывается 20 байтов.
• Повторное кодирование символа Pi π из \xF0 (\360) в iso-8859-7 в \xCF\x80 (\317\200) в UTF-8 добавляет байт.

Проверьте ожидаемый размер.