Question

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.

Answer 1

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 have cvs/master, cvs/HEAD, etc. pointed locally by master.
• authors-file.txt is the file that contains the matches between CVS account and Name+email, each line contains userid=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 as project_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.