git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jamey Sharp <jamey@minilop.net>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <johannes.sixt@telecom.at>,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: [PATCH v3 1/3] Support multiple virtual repositories with a single object store and refs
Date: Tue, 24 May 2011 18:21:00 -0700	[thread overview]
Message-ID: <7vr57n60eb.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1306284392-12034-1-git-send-email-jamey@minilop.net> (Jamey Sharp's message of "Tue, 24 May 2011 17:46:30 -0700")

Jamey Sharp <jamey@minilop.net> writes:

> 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.

  parent reply	other threads:[~2011-05-25  1:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-25  0:46 [PATCH v3 1/3] Support multiple virtual repositories with a single object store and refs Jamey Sharp
2011-05-25  0:46 ` [PATCH v3 2/3] Support virtual repositories in smart http-backend, specified by environment Jamey Sharp
2011-05-25  0:46 ` [PATCH v3 3/3] Add documentation for virtual repositories Jamey Sharp
2011-05-25 16:07   ` Jeff King
2011-05-25 17:01     ` Shawn Pearce
2011-05-25 17:10       ` Jeff King
2011-05-26 18:28         ` Shawn Pearce
2011-05-25 17:20     ` Junio C Hamano
2011-05-25 18:03     ` Josh Triplett
2011-05-25  1:21 ` Junio C Hamano [this message]
2011-05-25 16:08   ` [PATCH v3 1/3] Support multiple virtual repositories with a single object store and refs Jamey Sharp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr57n60eb.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jamey@minilop.net \
    --cc=johannes.sixt@telecom.at \
    --cc=josh@joshtriplett.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).