- 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>
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