[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

2009/5/30 Nick Woolley [off-list ref]:

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?

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.

 - 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"

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

-- 
Alex, homepage: http://www.bennee.com/~alex/
CV: http://www.bennee.com/~alex/cv.php

Alex Bennee wrote:

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.

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