Re: synchronizing incremental git changes to cvs

Jim Meyering <jim@meyering.net> writes:

I do not use the automated tools myself, but I sync the day-job work in my git repository to CVS at work. I do not develop with CVS but use it merely as a publishing medium. Although other people can make commits into CVS in which case I have to slurp the change back into my git repository.

 (0) Bootstrap.  I did use git-cvsimport myself (this repository
     started before the tool was written).  Instead:

     . cvs checkout the tip of the CVS development history

     . "git init-db", edit .gitignore to ignore CVS, and "git
       add ."

     . "git commit -m epoch"; the git side of development
       history in this repository starts at that point for me. 

     . "git branch origin"; the tip of CVS repository is kept
       track of with this branch.  I work in "master".

     I think I could have done the above with git-cvsimport,

 (1) Beginning of the day.  In case other people did work on
     the CVS side, I do this:

     . "git checkout origin", "cvs -q update".  If there is no
       change, go to step (3).

     . add any new files with "git add", and update the "origin"
       branch with "git commit -a -m 'from CVS'".

 (2) Merge other's work into my git master branch.

     . "git checkout master" and "git pull . cvs"; conflict
       resolve as needed.

 (3) Do my work.

     . "git checkout master" if I haven't done so.     

     . hack away, grow "master" branch using full power of git
       including the use of topic branches etc.

 (4) Publish, when "master" changes are ready.

     . To avoid conflicts with other people working on CVS,
       perform (1) again to make sure "origin" matches the tip
       of CVS.

     . "git checkout origin", "git pull . master".

     . generate the consolidated log I am about to push back to
       CVS with "git log --no-merges ORIG_HEAD.. | git shortlog >L".

     . add any new files with "cvs add", and "cvs commit -F L"

     . go back to (3) and continue.

This can be extended to multiple CVS branches. Per one CVS branch, use one git branch to track its head (plays the role of "origin" in the above), use another to do the real development for that branch ("master" in the above). Never use merges on the CVS side, but perform merges on the git side and then pushing the merge result back to CVS. This frees you from the nightmarish branch management.

The above obviously have advantages and disadvantages.

 . I do not use any git import tool, so in theory you can apply
   this to _any_ foreign SCM.

 . I treat the foreign SCM as a second class citizen; multiple
   commits made there are rolled into a single commit on the git
   side (the real project history as far as I am concerned),
   which may or may not be nice.  The people who see my work
   through CVS see multiple commits on git side as a single
   commit in CVS.

In my situation this is fine as is, but I think you could leave the management of "origin" to git-cvsimport (then your working tree would not have CVS metadirectories as the above outline does) if you wanted to avoid the "rolled into one commit" issue.

Pushing the changes on the git side back to CVS may become trickier (and that is why I still keep the above setup without using git-cvsimport), as I do not offhand know how exportcommit works. The commits on the git side you would want to push back are the ones on "master" but not on "origin", which you can get from "git rev-list origin..master", so I presume if you feed that to exportcommit things all magically work?

By the way, I met Paul a few days ago and he mentioned that you have some quick audit results on our code from your evaluation. Can we expect fixes or at least pointing-out-problems from you sometime soon please?