How to import and keep updated a CVS repository in Git?
With recent version git cvsimport
is broken, because of cvsps
tool incompatibility.
So you've to install cvsps-2.1
.
On OSX you can (having brew
):
brew tap homebrew/versions
brew install cvsps2
brew unlink cvsps
brew link --overwrite cvsps2
And import on empty git repository as usual, e.g.:
git cvsimport -C RepoName -r cvs -o master -k -v -d:pserver:[email protected]:/cvsroot/path ModuleName
You can also use cvs2git
tool which can convert a CVS repository to git. However you need to have access to a CVSROOT directory.
Check cvs2git documentation for installation steps.
Example usage:
cvs2git --blobfile=git-blob.dat --dumpfile=git-dump.dat --username=cvs2git /path/to/cvs/repo
This would create two output files in git fast-import format. The names of these files are specified by your options file or command-line arguments. In the example, these files are named cvs2git-tmp/git-blob.dat
and cvs2git-tmp/git-dump.dat
.
These files can be imported into empty git repository by:
cat git-blob.dat git-dump.dat | git fast-import
Then delete the TAG.FIXUP
branch and run gitk --all
to view the results of the conversion.
Check for more, by running: cvs2git --help
.
I believe there is no ready to use recipe in your case. But, you can try following:
- Manually synching CVS data with Git, or write scripts for that. They will get information from CVS and put it to Git. This will give you some kind of history in Git. Not fully clean, not fully usable, but still.
- Migrate your CVS repository to Git using tools like
git cvsimport
. And ask Git to pretend to be CVS for other developers, usinggit cvsserver
.
What I have done in the past is:
Import the CVS repository
Using:
$ git cvsimport -C target-cvs -r cvs -k -vA authors-file.txt -d $CVSROOT module
Where:
target-cvs
is the directory to keep my local copy of the repository.cvs
is the name to use for referencing the remote repository. So, I will havecvs/master
,cvs/HEAD
, etc. pointed locally bymaster
.authors-file.txt
is the file that contains the matches between CVS account and Name+email, each line containsuserid=User Name <useremail@hostname>
$CVSROOT
is the CVS respository server. If I use an anonymous cloning from some sourceforge repository, then I would use::pserver:anonymous@project_name.cvs.sourceforge.net:/cvsroot/project_name
module
is the module inside of the repository I want to clone. If the repository has only one module, then likely will be the same asproject_name
.
Update the repository
It is possible to repeat the command I wrote previously. In that particular example, it should be run in the parent directory of target-cvs
. To make it easier in the future, you might want to configure some variables (you can read more details in the answer of "How to export revision history from mercurial or git to cvs?")
$ git cvsimport
That would be enough to keep the local repository in git
synchronized with the remote one in CVS.
Daily work
From now on, every change should go in a local git branch. One feature, one branch. For this, I use a work flow described in "A successful Git branching model". The only difference is that master points to CVS, but conceptually the same work flows can be applied here. It is just a convention.
Once your commit is pushed in CVS, it will be back to master in the next update (git cvsimport
). Then, you can remove the local branch that implemented that feature.
For work in progress (in local branches), you should rebase
them against master. Because you have the features separated, it should be easier to solve conflicts. The tricky part is when some branches depend on others, but still manageable. Micro commits helps a lot (as in any git work flow).
If every local branch is rebased and master never touched (except for updates), then git
cvsexportcommit
should just work. Remember, it works for one commit. It is a bit tedious, but it is better than nothing. Given the previous example the command should be something like:
$ git cvsexportcommit -vc commit-id
If you only have read-only access to the remote CVS, then you can send the patches by email or make your git repository public, so the commiters can grab your patches to apply them. Nothing different from a normal work flow of CVS in this case. Again, in the next update you will see the changes in master.