Re: RFC: Another proposed hash function transition plan
- From
Mike Hommey <mh@glandium.org>
- Date
- Mar 7, 2017, 00:03 UTC
- Message-ID
- <20170307000315.6cywmnx35ip7ftmc@glandium.org>
- In-Reply-To
- <20170306234030.GB26789@aiede.mtv.corp.google.com>
On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote:
Show 22 quoted lines
> David Lang wrote: > > >> Translation table > >> ~~~~~~~~~~~~~~~~~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk. The exact format > >> of that mapping is to be determined. > >> > >> All operations that make new objects (e.g., "git commit") add the new > >> objects to the translation table. > > > > This seems like a rather nontrival thing to design. It will need to > > hold millions of mappings, and be quickly searchable from either > > direction (sha1->new and new->sha1) while still be fairly fast to > > insert new records into. > > I am currently thinking of using LevelDB, since it has the advantages of > being simple, already existing, and having already been ported to Java > (allowing JGit can read and write the same format). > > If that doesn't work, we'd try some other key-value store like Samba's > tdb or Kyoto Cabinet.
FWIW, I'm using notes-like data to store mercurial->git mappings in git-cinnabar, (ab)using the commit type in tree items. It's fast enough.
Mike