Re: forking on checkin vs. on checkout

David G. Durand (
Wed, 20 Jan 1999 10:26:06 -0500

Message-Id: <v04011704b2cba578be05@[]>
In-Reply-To: <>
Date: Wed, 20 Jan 1999 10:26:06 -0500
From: "David G. Durand" <>
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

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      \
Boston University Computer Science        \  Sr. Analyst   \  Dynamic Diagrams
MAPA: mapping for the WWW                    \__________________________