- 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>
On Sun, 9 Sep 2007 12:55:44 +0100, Jamie Lokier <jamie@shareable.org> wrote: <snip> > 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? <snip> 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. -- Travis
Received on Sunday, 9 September 2007 12:37:59 UTC