Chris Cowan <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> Irrelevant for CVS, which uses dot-locking that works fine in AFS.
> Well call me skeptical, but have you actually stressed this in a variety
> of situations or are you just basically working with a small group of
> well behaved developers (very little merging and conflicts), from your
> own machine (the one cache manager case)?
We have a small, fairly well-behaved group of developers. We do do
branches and merges, mostly merges from vendor branches but occasionally
other kinds, and we definitely all work from different machines and don't
use the same cache manager.
It's also used for courses here, which often have a lot heavier usage and
more frequent conflicts and the like (student programmers often aren't
well-behaved). I've never heard of problems.
Regardless of that, though, POSIX locking has absolutely nothing to do
with CVS. It simply doesn't. CVS doesn't use it, or at least doesn't
need to use it. It uses a variety of dot-locking in the lock directories,
when set up that way (which you certainly should for AFS), and that works
just fine with AFS.
> Have you included cases where multiple users attempt to commit the same
> module, from different machines (and thus multiple cache managers)?
Yes, we have done this.
> I can visualize a number of scenarios where things may not go totally
> smoothly. (Suppose I lose Network connectivity during a commit? Do I
> have to get multiple people to flush cache managers in order to
> guarantee a successful commit?)
No, because this is why CVS locks. This is the whole point of locking,
and AFS does not rely on POSIX file locking.
> Sorry, but I've been bitten by the non-POSIX filesystem semantics of AFS
> enough times in the past, that I would want to thoroughly test this.
You haven't been bitten by POSIX file locking with CVS because CVS doesn't
use it. AFS commits file creations immediately under most circumstances,
which is what CVS needs.
> I disagree. It's trivial for an AFS admin, not necessarily a general
> user.
The AFS admin can make instructions that will be trivial for someone else
to follow; I've done some of this before. I'd consider it part of the job
of an AFS admin. It's trivial once you understand AFS directory ACLs,
which is the hard part.
For a simple, one-project repository, just give everyone write access to
the whole repository and it works fine. The more complicated setup is
only needed if you want to limit who can modify CVSROOT.
> I'm really recommending pserver.
I would never recommend pserver to anyone, even someone who *has* to use
client/server or has to support anonymous repository access. I really
think this is bad advice in most circumstances, although I'm sure it does
work for some people. I consider pserver to inherently be a security
risk, not to mention difficult and complicated to set up in a fashion that
provides any security guarantees.
Client/server works great over either ssh or Kerberized rsh, both of which
I've used with quite a bit of success.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
