Ingo Molnar wrote: > with a plaintext repository we could do the 'hardlink trick' (which > brings in other manageability problems and limitations but is at least a > partially good idea), which would make the working tree and the > repository share the same inode in most cases. > > While in the compressed case we'd have a separate compressed inode > (taking up RAM with all its contents) and the working directory inode > (taking up RAM) - summing up to more RAM than if we only had a single > inode per object. > > furthermore, when generating/destroying large trees (which is a quite > common thing), a hardlinked solution is faster, as it doesnt create > 250MB+ of dirty RAM. In some cases (e.g. handling dozens of 'merge > trees') it's dramatically faster. You could still have the hardlink way by way of a .git/cache that keeps uncompressed files, keep the files with their hash names but uncompressed. It will be easy to find, fully hard-linkable, only keep the needed files uncompressed and the three year old file compressed. The You can even save some CPU time by checking if the file is in the cache before decompressing it, though it does cost you with an extra disk access to see if it's there or not. If you repeat the operation enough you'll have the uncompressed version in the cache most of the times anyway. Clear the cache weekly or so to avoid stale files from an ancient version. Baruch - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Apr 13 13:29:21 2005
This archive was generated by hypermail 2.1.8 : 2005-04-15 12:56:42 EST