Re: parsecvs tool now creates git repositories

From: Keith Packard <keithp@keithp.com>
Date: Apr 4, 2006, 03:51 UTC
Message-ID: <1144122709.2303.153.camel@neko.keithp.com>
In-Reply-To: <46a038f90604031942w779894b8p5ef221482a70a301@mail.gmail.com>

On Tue, 2006-04-04 at 14:42 +1200, Martin Langhoff wrote:

> Cool. What's the matter with the Pg repo? (Where can I get hold of that repo?)

As usual, the detection of branch locations is messed up.

The postgresql CVS tree is available at:

        rsync anoncvs.postgresql.org::pgsql-cvs/* postgresql.cvs

It's a fairly hefty 300M.

Show 10 quoted lines

> > > Does it run incrementally? Can it discover non-binary files and pass -kk?
> >
> > It doesn't run incrementally, and it unconditionally passes -kk. It's
> 
> I thought that the .git-cvs directory it created was to be able to run
> incrementally (btw, I think it's fair game to create subdirs inside
> .git for this kind of status-tracking). And passing -kk uncoditionally
> is destructive in some cases (I know... git-cvsimport does it, and I
> want to fix that). If you can ask rcs about the mode if the file and
> not pass -kk for binary files...

nah, the .git-cvs directory is purely for debugging; I leave the various command outputs there so I can see what went wrong.

I don't really have a good idea of how we'd do this process incrementally; that's not something I am personally interested in either, I want to run screaming from CVS as fast as I can at this point.

Show 5 quoted lines

> > currently using rcs to check out versions of the files, so it should
> > deal with binary content as well as rcs does. Is there something magic I
> > need to do here? Like for DOS?
> 
> We'll let DOS take care of itself ;)

I did discover that rcs has less sophisticated keyword substitution than cvs; not having any ability to customize stuff.

I guess we need to figure out when to pass -ko and when to pass -kk. The other alternative I'd like to get around to trying is to directly generate all of the revision contents from the ,v file.

I've just changed parsecvs to generate blobs for every revision in each ,v file right after they're read in; putting the necessary code right into parsecvs should be reasonably straightforward; we don't need the multi-patch logic as we do want to compute each intermediate version of the file.

With the blobs all generated, the rest of the operation is a simple matter of building suitable indices and creating commits out of them. That's a reasonably fast operation now as it doesn't manipulate any file contents. Plus, I can do all of the index operations using a single git-update-index command, so I eliminate a pile of forking.

Doing the file revision generation in-line would allow us to eliminate most of the remaining forks; we'd run one git-hash-object per file (or so), then a git-update-index, git-write-tree and git-commit-tree per resulting commit.

-- 
keith.packard@intel.com