On Mon, 27 Oct 2008, Brandon Casey wrote: > Jakub Narebski wrote: > > On Mon, 27 Oct 2008, Arne Babenhauserheide wrote: > > > > > > Also, looking at git, git users still have to garbage collect regularly, which > > > shows to me that the design wasn't really cleaner. > > > > Well, they have to a lot less than they used to, and there is > > "git gc --auto" that can be put in crontab safely. > > I think you missed the most convincing argument _for_ explicit garbage collection. > > By allowing explicit repository packing, git allows you to delay a cpu intensive > operation til later, when time doesn't matter, like at the end of the day right > before I go home. It also allows more cpu intensive delta/compression algorithms > to be used. > > By contrast, mercurial performs deltafication and compression on each commit. > So, acceptable commit speed must be weighed against the complexity of the > deltafication/compression algorithm and file format. On the one hand one can use different compression for loose (immediate) and packed (in a free time) objects. On the other access from "smart" client (git://, ssh://, future "smart" HTTP server) results in creating a pack, so we cannot allow for too tight pack compression, or to be more exact too much CPU load taken. The ability to vary 'quality' of pack compression is very useful to distinguish between very loosely packed fast-import pack, and tightly repacked in free time. -- Jakub Narebski Poland -- 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
