W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

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

From: Jamie Lokier <jamie@shareable.org>
Date: Sun, 9 Sep 2007 16:28:16 +0100
To: Travis Snoozy <ai2097@users.sourceforge.net>
Cc: Adrien de Croy <adrien@qbik.com>, Yaron Goland <yarong@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, Henrik Nordstrom <henrik@henriknordstrom.net>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070909152816.GA22349@mail.shareable.org>

Travis Snoozy wrote:
> That said, a "check out, modify, check in" approach may be more
> user-friendly than a "sync, merge, check in" approach -- the former
> results in access-denied (can't get the lock), so it limits the rate at
> which changes can come in, but the latter has the chance to cause
> headache-inducing merge conflicts, which even developers hate having to
> deal with.

"check out, modify, check in" is more about locking than
unsynchronised patching.  If PATCH requests were done with locks, we
wouldn't be having this conversation :-)

Both the above methods are more user friendly for some things.

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.

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.

-- Jamie
Received on Sunday, 9 September 2007 15:28:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC