Greg Stein <gstein@lyra.org> writes:
> In any case: get out of the "source code" mindset. Think about other kinds
> of documents. Locking is required for almost any non-mergable file format.
> Karl likes to say "but communication solves all that". It sure does, but the
> amount of communication necessary is hella more painful than a flag bit.
No, that's *not* what Karl likes to say :-).
The problem with the email method the Excel users were using was not
that it was communication instead of locking. The problem was that it
was a bad communication mechanism. The receipt/acknowledgement of the
message were not built into same the tools used to fetch and commit
the spreadsheet. So an unsynchronized channel -- email -- had to be
used instead. But if the transmitter of the message could know that
the transmission method were reliable -- in other words, that anyone
who needs to receive his message probably *will* receive it -- then
there would be no need for the time-wasting acknowledgement cycle Greg
described.
What Karl really likes to say is that if the point of a locking system
is really to be a communication system, then let's just go all-out and
make it a communication system instead of a locking system.
That is, we all seem to agree that a lock is essentially a very
low-bandwith channel, which you can use to communicate this tiny piece
of information:
"Hey, I'm working on foo right now, so please don't start anything
on it without talking to me first."
The successful transmission of that message to anyone thinking of
editing foo totally solves the Excel spreadsheet problem you
described, Greg.
And none of this requires the revision control system to "lock" the
file. What I'm describing is a reliable "warning" system, not a
locking system. So far, every scenario I've seen used to justify
locking would be solved equally well, or better, with a good warning
system.
Now, perhaps part of the warning would be to make the file read-only,
or as a last resort to insist that any commit be --forced. We can
call that a "locking" system if we want, fine with me. But the point
is that nothing is really locked, it's just that the user is being
told in some unmistakable way that someone else wants them not to do
something. (And obviously, a good system will say who that someone
else is -- which imho is just more evidence that this is really a
problem of getting the right information to the right place in time,
i.e., of communication).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 18:23:00 2002