Ответ 1
То, что я делал в прошлом, это:
Импортировать репозиторий CVS
Использование:
$ git cvsimport -C target-cvs -r cvs -k -vA authors-file.txt -d $CVSROOT module
Где:
-
target-cvs
- это каталог, в котором хранится моя локальная копия репозитория. -
cvs
- это имя, используемое для ссылки на удаленный репозиторий. Итак, у меня будутcvs/master
,cvs/HEAD
и т.д., Локально обозначенныеmaster
. -
authors-file.txt
- это файл, содержащий совпадения между учетной записью CVS и именем + email, каждая строка содержитuserid=User Name <[email protected]>
-
$CVSROOT
- сервер репозитория CVS. Если я использую анонимное клонирование из некоторого репозитория sourceforge, я бы использовал::pserver:[email protected]_name.cvs.sourceforge.net:/cvsroot/project_name
-
module
- это модуль внутри репозитория, который я хочу клонировать. Если репозиторий имеет только один модуль, то, вероятно, будет таким же, какproject_name
.
Обновить репозиторий
Можно повторить команду, которую я написал ранее. В этом конкретном примере он должен быть запущен в родительском каталоге target-cvs
. Чтобы упростить работу в будущем, вам может понадобиться настроить некоторые переменные (вы можете прочитать более подробную информацию в ответе Как экспортировать историю изменений из mercurial или git в cvs? ")
$ git cvsimport
Этого было бы достаточно, чтобы локальный репозиторий в git
был синхронизирован с удаленным в CVS.
Ежедневная работа
Отныне каждое изменение должно идти в локальной ветки git. Одна особенность, одна ветвь. Для этого я использую рабочий поток, описанный в успешная git ветвящаяся модель". Единственное отличие состоит в том, что мастер указывает на CVS, но концептуально здесь могут применяться те же рабочие потоки. Это просто соглашение.
Как только ваша фиксация будет нажата в CVS, она вернется к следующему обновлению (git cvsimport
). Затем вы можете удалить локальную ветвь, которая реализовала эту функцию.
Для незавершенного производства (в локальных ветвях) вы должны rebase
их против хозяина. Поскольку у вас есть функции, разделяемые, нужно будет легче разрешать конфликты. Трудная часть заключается в том, что некоторые ветки зависят от других, но все же управляемы. Микрокоманды помогают много (как в любом рабочем процессе git).
Если каждая локальная ветвь переустанавливается и мастер никогда не касается (кроме обновлений), тогда git
cvsexportcommit
должен работать. Помните, что он работает для одного фиксации. Это немного утомительно, но это лучше, чем ничего. Учитывая предыдущий пример, команда должна выглядеть примерно так:
$ git cvsexportcommit -vc commit-id
Если у вас есть доступ только для чтения к удаленному CVS, вы можете отправлять исправления по электронной почте или публиковать публичный репозиторий git, поэтому участники могут захватить ваши патчи для их применения. В этом случае ничто не отличается от нормального рабочего потока CVS. Опять же, в следующем обновлении вы увидите изменения в master.