Re: [PATCHv2 1/2] Support multiple virtual repositories with a single object store and refs

[Jamey Sharp <jamey@minilop.net>]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Wed, May 25, 2011 at 08:51:07AM +0200, Johannes Schindelin wrote:
> On Tue, 24 May 2011, Junio C Hamano wrote:
> > Jamey Sharp <jamey@minilop.net> writes:
> > > 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.  Git safely handles 
> > > concurrent accesses to the same object store across repositories, but 
> > > operations such as gc need to know about all of the refs.
> > >
> > > This change adds support in upload-pack and receive-pack to simulate 
> > > multiple virtual repositories within the object store and references 
> > > of
> > 
> > Is it just me to read the above and then have to re-read the first 
> > sentence of the second paragraph over and over again?  There seems to be 
> > a huge gap in logic flow, probably largely due to the use of undefined 
> > term "virtual repository".
> 
> I had to read the example call to understand that 'virtual repository' 
> means 'one real catch-em-all repository'.
> 
> I wonder about two things, though:
> 
> 1) Would teaching git clone to understand "-t this/repo/*" help?

Sure, that would be an improvement for our use case, but we expect to
have lots of these virtual repositories, so I think we'd rather have the
server-side help we proposed in these patches. Seems to me that
wildcards in git-clone would be nice for other use cases, though.

> 2) You're extending the protocol by appending the prefix after the SHA-1, 
>    and I stopped halfway through the patch trying to find information 
>    which I now think should be in the commit message: a) why? b) why does 
>    it not break when one of the two sides is a previous version?

I don't think we're changing the protocol in any way...? In all of our
tests, the client was Debian's package of git version 1.7.5.1. And note
that none of these patches touch client-side protocol code; it's all in
the server-side upload-pack and receive-pack.

If we have changed the protocol, it was unintentional and we should fix
it.

Jamey

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]