How to import and keep updated a CVS repository in Git?
There is a central repository in CVS, and I would like to use it with Git locally, and then send my changes back to CVS.
What can I accomplish that on a daily basis?
The tasks I would like to accomplish are:
- importing branches,
- getting history in GIT-like format, and
- exporting back my changes/commits to the centralized server
BTW, I have also looked at Best practices for using git with CVS . But It didn’t work and I couldn’t figure out what I missed or did wrong.
3 Solutions collect form web for “How to import and keep updated a CVS repository in Git?”
What I have done in the past is:
Import the CVS repository
$ git cvsimport -C target-cvs -r cvs -k -vA authors-file.txt -d $CVSROOT module
target-cvsis the directory to keep my local copy of the repository.
cvsis the name to use for referencing the remote repository. So, I will have
cvs/HEAD, etc. pointed locally by
authors-file.txtis the file that contains the matches between CVS account and Name+email, each line contains
userid=User Name <useremail@hostname>
$CVSROOTis the CVS respository server. If I use an anonymous cloning from some sourceforge repository, then I would use:
moduleis the module inside of the repository I want to clone. If the repository has only one module, then likely will be the same as
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.
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 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.
With recent version
git cvsimport is broken, because of
cvsps tool incompatibility.
So you’ve to install
On OSX you can (having
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:firstname.lastname@example.org:/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.
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
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:
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, using