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: Travis Snoozy <ai2097@users.sourceforge.net>
Date: Sun, 9 Sep 2007 05:37:49 -0700
To: Jamie Lokier <jamie@shareable.org>
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: <20070909053749.353304c6@localhost>

On Sun, 9 Sep 2007 12:55:44 +0100, Jamie Lokier <jamie@shareable.org>

> In my experience version control software uses first-in-wins and
> everyone else has to resync and fix conflicts locally before they can
> submit their changes to a shared server.  CVS and SVN work this way,
> for example.  What VC software are you thinking of?

Preventing unsynchronized checkins is a defining part of source control
systems -- it's one of the primary reasons we have them. Allowing Bob
to check in V3 of a file that fixes bug 42, overtop Alice's V2 checkin
that fixed bug 7 (where they both made their changes starting from V1),
would cause mass confusion, potential loss of work (if the lack of a
merge goes unnoticed) and extra time and energy spent trying to get
everything merged later on (after possibly more changes came in). Bob
must make sure that his changes apply to the repository's HEAD before
he has any business trying to commit those changes, and the system
enforces this.

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.

Received on Sunday, 9 September 2007 12:37:59 UTC

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