Re: [PATCH v3 1/3] Support multiple virtual repositories with a single object store and refs

From: Junio C Hamano <gitster@pobox.com>
Date: May 25, 2011, 01:21 UTC
Message-ID: <7vr57n60eb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1306284392-12034-1-git-send-email-jamey@minilop.net>

Jamey Sharp <jamey@minilop.net> writes:

Show 12 quoted lines

> From: Josh Triplett <josh@joshtriplett.org>
>
> Given many repositories with copies of the same objects (such as branches of
> the same source), sharing a common object store will avoid duplication.
> Alternates provide a single baseline, but don't handle ongoing activity in the
> various repositories.  Furthermore, operations such as git-gc need to know
> about all of the refs.
>
> Git supports storing multiple virtual repositories within the object store and
> references of a single underlying repository.  The underlying repository
> stores the objects for all of the virtual repositories, and includes all the
> refs and heads of the virtual repositories using prefixed names.

I do not see anything changed up to this point since the previous round... sent a wrong patch?

In any case, I _think_ what you are trying to say is:

 - Implemented in the most naïve way, you can host multiple instances of
   related projects, but that is wasteful; their object stores will have
   duplicated objects without sharing. (This is the crucial part missing
   from your description that confused me when trying to _guess_ what
   problem you are trying to solve in the first place).

 - You _could_ use alternates mechanism to alleviate that problem, but it
   has issues, e.g. gc needs to be aware of other repositories (This is in
   your first paragraph).

 - Instead, we could store a single, large, repository and carve out its
   refs namespaces into multiple hierarchies, to make it look as if there
   are multiple repositories. (The first sentence of the second paragraph
   also confused me, as you said "Git supports storing multiple ..." in
   present tense).

One thing you would want to be careful with is what to do with the HEAD symrefs, which should appear to read "ref: refs/heads/<some-branch>" from the point of view of the clients that are under the illusion that they are interacting with one specific repository among others, while for the purpose of gc and things in the huge single repository they should be pointing at something like "refs/hosted-1-project/heads/<that-branch>", but other than that, after a lot of guesswork, the problem you are trying to solve seems clearer to me.

But please do not make me guess.