"Shawn O. Pearce" <spearce@xxxxxxxxxxx> wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html