On Tue, Mar 27, 2012 at 1:49 PM, elton sky <eltonsky9404@xxxxxxxxx> wrote: > Thanks Shawn, > >> Or use LevelDb[2]. Its BSD license. Uses an immutable file format, but >> writes updates to new smaller files and eventually collapses >> everything back together into a bigger file. This can be a >> dramatically simpler approach than dealing with your own free block >> system inside of a single file. Its only real downside is needing to >> periodically pay a penalty to rewrite the whole index. But this >> rewrite is going to be faster than the time it takes to rewrite the >> pack files for the same repository, which git gc or git repack >> handles. So I don't think its actually a problem for the index. >> >> You might even be able to take a two level approach to compacting the >> LevelDb database (or something like it). In a minor compaction you >> compact all of the files except the huge base file, leaving you with 2 >> files. A huge base file that contains the first tree the user checked >> out, and a second smaller file containing any differences they have >> since the initial checkout (this may just be updated stat data for a >> handful of files that differed across two branches as they switched >> back and forth). During a git gc or git repack, add a new stage to >> collapse the base file and everything else into a single new base file >> as a major compaction. >> >> [2] http://code.google.com/p/leveldb/ > > I don't know leveldb, but like to have a look. > Just realize this solution is kinda popular. HDFS also uses the > similar image file with edit file format for its file block index. Another implementation in this general class is TinyCDB[1]. It is <1600 lines of plain C. Too few to be complete? It is a derivative of DJB's CDB[2]. [1] http://www.corpit.ru/mjt/tinycdb.html [2] http://cr.yp.to/cdb.html -- David Barr -- 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