Re: Git / Subversion Interoperability

From: Eric Wong <normalperson@yhbt.net>
Date: Mar 24, 2007, 20:38 UTC
Message-ID: <20070324203813.GB25571@muzzle>
In-Reply-To: <20070324064556.GD25863@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:

Show 24 quoted lines

> Jakub Narebski <jnareb@gmail.com> wrote:
> > Shawn O. Pearce wrote:
> > 
> > > - Assigning repository-wide revision numbers.  Git doesn't have
> > > such a concept, but its key to SVN.  These would need to be stored
> > > in a file so the server can quickly map from revision number to
> > > Git commit SHA-1.  The reflogs may help here, but currently they
> > > also expire.  Any reflog that is being used to do this mapping
> > > cannot be expired, ever.
> > 
> > Another idea is to use lightweight tags for that, especially now
> > with packed refs support in git.
> 
> Yes, not a bad idea.
> 
> Except the packed refs file can have variable sized records.  It has
> no faster access path than to just scan it.  Some SVN repositories
> have revision counts up into the 5 and 6 digits.  These would take
> quite a while to scan, even as packed refs.  ;-)
> 
> I'm inclined to lean towards a really simple binary flat file holding
> just 20 byte SHA-1s, in "SVN order".  Then its just a simple array
> index operation to locate the correct Git commit.  And adding a
> new commit is really just an append to the end operation.

The rev_db implementation in git-svn is very similar to what you're describing. However, I decided on 41-byte (SHA1 ascii + "\n") records since it was easier to debug if any problems came up, and a ~50% size reduction wasn't worth the potential headache (I already had a lot of those from just dealing with SVN :).

The biggest weakness of fixed records is that tags or sparsely worked on branches waste a lot of disk space, but it hasn't been a huge problem for me.

-- 
Eric Wong