Karl Fogel <kfogel@newton.ch.collab.net> writes:
> I've CC'd Jim Blandy explicitly on this, because he had even broader
> experience using RCS back in the day, and may be able to give some
> insight here.
Less "insight", more "fear". I designed CVS's `edit' facility, which
is so clumsy that even I can't remember how to use it. I don't think
the client for whom we wrote it uses it either. CVS would be better
if we had never implemented it in the first place.
So far, this discussion scares the heck out of me. "Oh, look! If we
use properties, you've got to update before you can lock!" "No, we
want to see commit messages." "No, it must be compatible with DAV."
"How does this relate to ACL's?" The discussion is more about
Subversion's implementation than about the behavior we want to see.
I'd like to hear more about people's real-life situations, more at the
``project manager looking for good working procedures'' level, and
less at the ``Subversion implementor'' level. Karl's post about how
RCS locks behave with real people going on vacation is at the right
level. Bill Tutt hinted at more restrictive applications --- it would
be great to hear the whole story about those.
Someone said they like VSS's locking; tell us more. But tell us
something more analytical than just "we used VSS locking, and it was
helpful." That'll help us design something that would have helped
that group, on that project. But if you can see why locking isn't
helpful in some situations, then what was different about your
situation that made it the right thing?
Including a feature because it appears on conservative managers'
checklists is design by extortion. We're not that desperate --- the
"extortionists" don't really have much power over us. Shouldn't we
spend our limited energy on work we think will really be useful?
But maybe Karl really just wants me to give my "file locking doesn't
work" spiel. (This argument isn't meant to address Greg's point about
non-mergeable file formats.)
People often say they want locking because they believe that merging
introduces inconsistencies that people won't notice: Joe changes the
file here, Josephine changes it there, the changes get merged, and the
system doesn't work any more. They blame the copy-modify-merge
process.
But locking doesn't, in fact, prevent these problems. Suppose you
have files like so:
foo.h:
extern int foo (int a);
foo.c:
int
foo (int a)
{
blah blah blah;
}
bar.c:
int
bar ()
{
blah blah blah;
}
Now, suppose Joe locks bar.c, and adds an #inclusion of foo.h, and a
call to foo.
Simultaneously, Josephine locks foo.c, foo.h, and every file that
#includes "foo.h" (which, at this point, doesn't include bar.c), and
adds a new argument to foo.
Now they both commit, releasing their locks. Everyone locked every
file they needed, but now bar.c doesn't compile.
What file locking prevents are *textual* conflicts: multiple changes
to overlapping areas of the source code. But what we have above is a
*semantic* conflict, that only gets detected when the compiler handles
#inclusions and smooshes all the information together with lots of
consistency checks --- like the one that noticed that bar doesn't pass
the extra argument to foo.
So, file locks don't completely solve the problem they're supposed to.
They're an approximate solution, like merging. So, given a choice
between two approximate solutions, which one causes you less trouble,
net?
If you really need consistent or reliable trees, why not tackle the
problem more directly? Have a tinderbox process that continuously
checks out trees, builds them, tests them, and sticks a "test result"
property on the revision. Whoever needs the latest solid tree could
just find the latest revision that made the grade. Or whatever. And
if your developers are always committing changes that don't build,
well, tell them not to. You've got their user names sitting right on
the revisions marked "doesn't build" or "doesn't pass".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 00:34:01 2002