Re: [jgit-dev] [RFC] Cassandra based storage layer for JGit

[Adrian <adrian.wilkins@xxxxxxxxx>]

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.