Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

On Sun, 9 Sep 2007 16:28:16 +0100, Jamie Lokier <jamie@shareable.org>
wrote:

> Most groups of software developers use the "sync, merge, check in"
> method nowadays, but some use the locking method.  They _used_ to use
> the locking method more, but the CVS/SVN manuals have a nice section
> which explains how this tends to be a bottleneck more than it helps.

Which is irrelevant in the general case; it's a heuristic that works in
many cases, but assumes some degree of side-channel communication and
coordination which we cannot assume on the web. This is especially
true if we want to support autonomous or semi-autonomous systems being
able to patch things -- we need to be able to signal intent and
priority for submitting a patch, and a checkout does just that.

> Merge conflicts can be hard, but the locking method can force people
> to work outside the version control - by doing an unlocked checkout
> (because someone else has the file locked for a while), working, then
> waiting until they are able to sync manually, or submitting patches to
> the main auther.  Either way, merging conflicts occur.  It's better to
> have tools which support that, than doing it manually and prone to
> more mistakes.
> 
> Analagous things happen at a protocol level with PATCH.

Yes, you can always just check out, dump your file, check in. But the
point is that you don't get into the situation where Alice and Bob are
both editing a file simultaneously, and don't find out about this until
checkin. You don't have some mystery "what happens now?" coming when
someone who has checked out a file goes to check in, and clients who
start modifying a checked-out file have advance warning that there
could be merge conflicts. Does that mean clients should jettison merge
support? Not at all. In fact, a client could accept a PATCH back from
the server when acquiring the lock, to update the client view and aid
with merging. But the point is, there needs to be some cross-client
awareness to allow for the coordination that groups like developers
have naturally over the course of working on code with each other.

Checkouts let you make intelligent risk decisions up-front. That is
extremely desirable for conserving bandwidth and branwidth, especially
in cases where there is a lack of communication and coordination
between editors.

-- 
Travis

Received on Monday, 10 September 2007 00:55:27 UTC