Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

["Dana How" <danahow@gmail.com>]

On 4/12/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 12 Apr 2007, Dana How wrote:
> > These arguments all seem pretty convincing to me --
> > maybe the problem is that I'm not a "*developer*" right now.
> > Instead I'm part of a multi-developer *site*.
> 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.
For clarity I should have written *office* instead of *site* to
describe my situation,
but the mention of a NetApp below indicates no actual confusion occurred.

> 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).
We did go down the local disk route, but after two significant losses of
individuals' work,  it was decreed that (perforce) work trees must be
on the NetApp.  So we already made the investment in beefiness --
for different reasons -- and I need to conform to these decisions for
the moment.

After reliability, the other big criterion (especially with our
penchant for large files)
will be speed. With perforce,  users now see submit={1 copy to server},
sync={1 copy from server}.  In the short term I can't get away with changing
this to submit={copy working to indiv repo, copy indiv repo to shared repo}
and sync={copy shared repo to indiv repo, copy indiv repo to working},
because at first everyone will be trying to emulate what they did in perforce.

So probably I'll start out with either a very small testgroup,
or one shared object repository with sticky/group tricks on the NetApp.
Once git's collaboration advantages are apparent,
I'll switch to the hidden repository model which I prefer as well.
And hopefully these collaboration advantages will also mean people
will commit more often and local disks can come back into favor --
and then the "extra" local repo file copy operations will be less noticeable.

In any event, I have some scripting to do to learn more about our usage
patterns and pushing our datasets throught git.  I also need to finish
the pack-splitting patch (after 64b index goes in). Finally,  before all that,
I'll be out of the country for the next ~10 days...

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell