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

On Wed, Apr 13, 2011 at 1:47 PM, George Spelvin [off-list ref] 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.

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