Yes.
The issues for hosting sites are very different from the issues of
individual developers having their own git repositories, and I agree 100%
that both alternates and shared object directories make tons of sense for
hosting.
I hope it wouldn't even be a minority usage pattern. I am a firm believer
that distributed SCM's and git in particular makes a lot more sense for
source control hosting than CVS or SVN do. I'm really disappointed with
things like sourceforge, and part of the problem is literally that a
centralized SCM is really *fundamentally* wrong for a hosting entity.
Using a distributed SCM just makes _so_ much more sense for hosting
projects, and I've actually very much wanted to try to make sure that git
can help people who host things.
It's not my *own* primary use, but I think it's a very important usage
pattern, even though it's very different froma "normal developer" private
sandbox case.
So I think your case is really very interesting. I'd love to help figure
out how to help you guys with git, but because it's not how I personally
work, I can really just try to help when you actually hit a problem -
you'll have to figure out what your usage patterns actually are on your
own ;)
And btw, I think the shared object model really works very well, but I
think it has to be paired with some stricter rules than people who use
their own repos tend to have. For example, end-point developers have
become very used to rebasing and generally rewriting history (or just
resetting to an older state), and that's something that works find in a
"local repository" setup, but it's also the kinds of patterns that can
really screw you in a hosted and shared-object environment.
As to your two setups: I would suggest you go with the "hidden" shared
version (ie people use the remote access pull/push to a server, and the
*server* uses a shared object repository for multiple repositories),
rather than having a user-visible globally shared object directory. Even
with sticky bits and controlled group access etc, I think it's just safer
to have that extra level of indirection.
(Partly because a globally visible shared object directory also implies
that you'd use a networked filesystem, and I suspect a lot of developers
would actually be a lot happier having their own development repositories
on their own local disks, or at least some "group disk", rather than have
one big and performance-critical network share. Even if you use some
competent NetApp box and a modern network filesystem, it's just one less
critical infrastructure piece that needs to be really beefy).
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
