Re: is hosting a read-mostly git repo on a distributed file system practical?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 13, 2011, 04:57 UTC
Message-ID: <BANLkTi=cE4=EC0C4MA5iac6_O-YMsW_SLg@mail.gmail.com>
In-Reply-To: <20110413034715.15553.qmail@science.horizon.com>

On Wed, Apr 13, 2011 at 1:47 PM, George Spelvin <linux@horizon.com> wrote:

> I think the answers are yes, but I have to make a vouple of things clear:
> * You can *definitely* control repack behaviour.  .keep files are the
>  simplest way to prevent repacking.

Good.

Show 6 quoted lines

> * Are you talking about hosting only a "bare" repository, or one with
>  the unpacked source tree as well?  If you try to run git commands on
>  a large network-mounted source tree, things can get more than a bit
>  sluggish; git recursively stats the whole tree fairly frequently.
>  (There are ways to precent that, notably core.ignoreStat, but they
>  make it less friendly.)

Bare. Developers use local disk for local repos and working tree.

> * You can clone from a repository mounted on the file system just as
>  easily as you can from a network server.  So there's no need to set
>  up a server if you find it onconvenient.

Are there advantages to using rsync for the initial clone? Will I get better restartability in the case that the network is less than 100% reliable?

I do remember trying to use a DFS-file system in the past, before I understood pack management properly and I seem to recall issues with network reliability.

> Indeed, you could easily do everything via DFS.  Give everyone a personal
> "public" repo to push to, which is read-only to everyone else, and let
> the integrator pull from those.
>

I'll probably use ssh-secured peer to peer for publishing purposes. The main thing I want the DFS-hosted repo for is to provide a single, always up, go-to point for the shared tag set.

>
> Anyway, I hope this helps!
>

Yep, thank you.

jon.