Re: forking on checkin vs. on checkout

David G. Durand (dgd@cs.bu.edu)
Wed, 20 Jan 1999 10:26:06 -0500


Message-Id: <v04011704b2cba578be05@[24.0.249.126]>
In-Reply-To: <m102xJQ-000OW3C@jazzie.com>
Date: Wed, 20 Jan 1999 10:26:06 -0500
To: ietf-dav-versioning@w3.org
From: "David G. Durand" <dgd@cs.bu.edu>
Cc: ietf-dav-versioning@w3.org
Subject: Re: forking on checkin vs. on checkout

At 8:04 AM -0500 1/20/99, Sean Shapira wrote:
>Does this imply that a fork occurs as soon as a second check-out
>is performed on a revision?  The alternative model delays the fork
>until the second check-in is performed.  That approach has some
>major benefits, not the least of which is that the second user to
>check-in can be given the option of merging all the changes and
>thus avoiding the fork altogether.
>
>Another alternative model has the fork happening on check-out,
>but doesn't give either child revision special status until the
>first one is checked in.  In particular, until a check-in occurs
>one wouldn't know which child will become the immediate successor
>on the same branch as their shared parent, and which -- in the
>absence of a merge -- would be shunted off to a side-branch.
>
>Either of these alternatives supports a less structured style
>of cooperative work, without sacrificing any revision-control
>rigor.

Hear hear!

I still think servers need to have the flexibilty to decide which
operations (CHECKIN/CHECKOUT) _actually_ cause forking to occur. Whether we
want to allow headers for clients to _request_ they happen at particular
times is a different question.

  -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________