[RFC] git-cvs script

[RFC] git-cvs script

[Nick Woolley]

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

Re: [RFC] git-cvs script

[Junio C Hamano]

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

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

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.

> It's not currently as sophisticated as git-svn,...
> ...
>  - Is this at all useful to anyone else in it's current form?

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

Re: [RFC] git-cvs script

[Nick Woolley]

Junio C Hamano wrote:
> 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.

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?

>>  - Is this at all useful to anyone else in it's current form?
> 
> I have to admit that it won't be to me (because I do not interact with CVS
> myself) but I don't count ;-)

An enviable position to be in, sir.


N

Re: [RFC] git-cvs script

[Alex Bennee]

2009/5/30 Nick Woolley <nickwoolley@yahoo.co.uk>:
> 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

Re: [RFC] git-cvs script

[Nick Woolley]

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