From: Jon Seymour Date: Wed, 13 Apr 2011 04:57:10 GMT Subject: Re: is hosting a read-mostly git repo on a distributed file system practical? Message-ID: In-Reply-To: <20110413034715.15553.qmail@science.horizon.com> On Wed, Apr 13, 2011 at 1:47 PM, George Spelvin 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.