|Re: [jgit-dev] [RFC] Cassandra based storage layer for JGit|
On Fri, Jan 28, 2011 at 10:56 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > > Again, why not repack these? I would guess that I'm not understanding the triggers on which the code packs loose objects - my understanding of this part is based only on watching the output of C git and is thus vague. My concern is just that loose object files will accumulate beyond the limits of the file system they are on, especially on Windows. I am working under the assumption that packing only occurs after commits or when manually invoked, so inserting, for example, 350,000 objects at a time into the index to be committed might generate 350,000 loose object files which I would anticipate to be a little slow. These are just that, assumptions. I shall take a look at the relevant code. By and large, this is a large set of objects with a slow rate of change mediated by human editors, and loose object accumulation as files probably isn't a concern. But there are a few processes that deal with large sets of objects ; the initial construction of a commit graph would be one. There are some batch processes that import objects from other systems (although I'd anticipate the change count is much smaller than the actual object count there). > >> * Packed objects are in standard pack files >> ** Why bother with the overhead of storing them in another container >> ** Not doing this for the enterprise scaling or redundancy > > Why use a K/V store if you want standard pack files in your local filesystem? Only because of my concerns about loose objects. I guess I should just suck it and see first.
Back to the top