Given general-purpose properties, both historied and non-historied, I
don't think the filesystem should require any special-purpose features
to support reserved checkouts --- it can be implemented in the client.
Beyond not letting people modify files others have locked, there's no
way the filesystem can distinguish between a user locking a file
before they start editing (i.e., following the reserved checkout
policy properly), and the user locking the files immediately before
they do a commit (i.e., equivalent to unreserved checkouts). So since
the server can't enforce anything anyway, there's no harm in keeping
it simple, which is my big priority.
I think the most interesting issues here are in the human interface
side of things. I designed `cvs watch' and `cvs edit', and they suck
rocks. Nobody can remember how you're supposed to do things. Perhaps
someone on the list could describe a reserved checkout interface they
enjoyed using...
> Even though I am a huge fan of unreserved checkouts, I recently had
> the opportunity to teach CVS to a group of contractors who had only
> used VSS. When I explained the concept of copy-modify-merge, several
> of them were absolutely horrified at the concept. They really wanted
> the safety of locking/unlocking different bits of the repository,
> which is what they were accustomed to.
Yeah, that's a pretty common reaction. I felt that way when I moved
from RCS to CVS. "You're just going to throw their stuff into my
sources???" Here's the argument I would present to my classes:
In fact, reserved checkouts don't prevent conflicts.
For example, suppose I have a header file foo.h:
int foo (int);
and I have a source code file bar.c:
int bar () { return 9; }
User A can lock foo.h and change it to this:
int foo (int, int);
User B can lock bar.c and change it to this:
#include "foo.h"
int bar () { return foo (3); }
They can now both commit their changes, even though there is a
conflict here. It's not a *textual* conflict, but it's a *semantic*
conflict, which is only revealed when the compiler stirs together
information from all these different places.
Conflicts are a fact of working together on a team. You can't prevent
them by applying locks to certain blocks of text --- the only way to
cope is by communicating well with your team. And if you're
communicating well with each other, then your version control system
shouldn't prevent you from making the majority of changes that don't
conflict.
Reserved checkouts can be a great thing if they effectively aid that
communication. "Oh, Moira's editing that." But it seemed like I
always hit locks people had forgotten to remove, or from people who
had gone home, or people editing other functions in the same file,
etc. They were so inaccurate that they weren't effective
communication.
Which is why I bring up the human interface stuff. I think the real
contribution to be made here is helping teams work together.
But I suppose people just want what they want. *sigh*
Received on Sat Oct 21 14:36:12 2006