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