[RFC] git-cvs script

Hi,

I have script which wraps git-cvsimport and git-cvsexport, called "git-cvs".

The main aim of the script is to automate the steps for tracking a CVS repository with the git-cvs* commands.

It's not currently as sophisticated as git-svn, it's undoubtably flawed and isn't foolproof (e.g. exports to CVS of merged git histories can be problematic), but I find it useful, because a lot of the nitty-gritty is done for me.

I'd like to ask:

 - Is this at all useful to anyone else in it's current form?

 - Is there any prior art I should be aware of? (Presumably most people
   just roll their own scripts, like I have)

 - Bearing in mind that it's a work-in progress, are there any suggestions for
   improvement?

The script can be found in its current state here:

 http://github.com/wu-lee/git-cvs/

There's no installer, but the script is self-contained and just needs to be on the execution $PATH (as well as git and cvs).

Given a CVS repository at $CVS_ROOT, tracking a module $CVS_MODULE can be done like this:

 # Create a git repo
 git init

 # Initialise git-cvs's config file
 echo cvsroot=$CVS_ROOT      >.git-cvs
 echo cvsmodule=$CVS_MODULE >>.git-cvs

 # First pull gets cvs files using git-cvsimport
 # (optionally you can supply the option
 # --author-file <authormap> for pass-through
 # to git-cvsimport -A on subsequent invocations)
 git-cvs pull

 # hack hack...

 # Push the files back into CVS with git-cvsexportcommit
 # (This pushes the commits master..remotes/cvs/cvshead by default,
 # or cvsworking/NAME..remotes/cvs/NAME for each CVS branch NAME)
 git-cvs push

 # Pull the changes back into remote/cvs/cvshead and
 # (a messy part I've not found a way round yet) throw away our
 # locally merged commits
 git-cvs pull
 git reset --hard master

 # More hacking...

 # Repeat push/pull steps as needed

Some other points:

 - Changes in CVS get pulled back, including multiple branches.

 - An author-mapping file can be supplied as for cvs-import -A

 - The script creates local CVS working directories
   .git/git-cvs/cvscheckout/NAME, one for each CVS branch NAME.

 - Git's master branch tracks CVS's HEAD branch.

 - A git branch cvsworking/NAME is created to track each CVS branch NAME.

 - Edits in these branches get pushed back to the appropriate CVS branches.

 - Verbose subcommand output currently goes into .git/git-cvs/logs.

 - Invoking git-cvs with no parameters gets information about the options.

 - In an emergency, a list of commit ids can be supplied to git-cvs push.

 - Written in Perl, uses only core modules (tested with v5.8.8)

 - There is a small test suite in t/, run individually or with "prove/*.t"

Thanks,

Nick

Nick Woolley <nickwoolley@yahoo.co.uk> writes:

If I recall correctly, the above is in line with the original spirit of how git-cvsexportcommit was envisioned to be used by its original authors.

That is, the import side is more or less satisfactory done in the sense that it deserved a short and sweet command name, but the export side is not as finished as the import side is, and you have to drive it more explicitly by telling what commit to send back to the CVS side. Building on top of it so the tool keeps track of what needs to be sent, like git-svn allows users to do, would be the right thing to do.

I have to admit that it won't be to me (because I do not interact with CVS myself) but I don't count ;-)

Junio C Hamano wrote:

Ok - thanks.

Apart from fixing significant bugs, for now I've been avoiding making any major changes to git-cvsexportcommit git-cvsimport, since understanding their guts takes a significant amount of time and effort.

On the other hand, if I ever did, then currently git-cvsexportcommit and git-cvsimport are separate commands. I would imagine they would want to share some code, like "push" and "pull" operations do in git-cvs. Is that possible/encouraged in the current scheme? (e.g. "use Git::CVS" - I notice there is a Git.pm in the source.) Or would this need to be done by rolling it all into a single command as git-svn seems to do it?

An enviable position to be in, sir.

N

2009/5/30 Nick Woolley <nickwoolley@yahoo.co.uk>:

If this is using the inbuilt cvsps and perl then it will likely choke on very large CVS repos. For some CVS tree's I've had to resort to a hacked up version of parsecvs to get a conversion running.

The other repo it tends to die on is ones which have been pruned (i.e. old branches have been cut off). But people there have made a decision to mess with their repo.

I'll give your script a spin on the repo I have here and I'll report on how it does :-)

Alex Bennee wrote:

I gather cvsps has to read the whole history to be able to interpret the latest commits, is that right? In which case a long history is going to generate long waits on each import. And possibly eat lots of memory too.

I do actually have a larger CVS tree to test it on than I have been using (it's about a decade's worth of changes on a production website) but I didn't want to set myself up for a fall by tackling it. For now, my aim has been to keep CVS "out of the living room" whilst I work on the small CVS module that concerns me. Meanwhile, I'm hoping to convince the powers that be that CVS needs to be replaced, preferably with Git, before I get asked to work on something larger.

However, if you can test it on your repository, and with your patched version of parsecvs, that would be a good thing. Especially if it works.

Thanks,

N