Re: forking on checkin vs. on checkout

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 20 Jan 1999 09:18:48 -0500 

Date: Wed, 20 Jan 1999 09:18:48 -0500
Message-Id: <9901201418.AA14370@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sds@jazzie.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <m102xJQ-000OW3C@jazzie.com> (sds@jazzie.com)
Subject: Re: forking on checkin vs. on checkout

   From: sds@jazzie.com (Sean Shapira)

   Geoff wrote:
   > Only one checkout of a given mutable-revision (branch) of a versioned
   > resource, yes.  If you want to check-out an already checked-out mutable-
   > revision (branch), you need to use the CHECKOUT-NEW method, which checks
   > out a new mutable-revision (branch) of the versioned resource.

   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.

Excellent question.

First the easy part, i.e. for mutable-revisions.  With
mutable-revisions, a CHECKOUT-NEW has to create a new revision,
because somebody else has checked out the current revision, and if you
make changes to it while that person has it checked out, you'd stomp
on that persons changes.

Now for the harder part, i.e. for immutable-revisions.  The key here
is that the protocol can be kept simple by just treating this as
something you tell the server once, (i.e. a property of your "workspace"),
and then when you perform a CHECKOUT, it looks at this property of your
workspace to see whether to do a "reserved" CHECKOUT-NEW (i.e. create the
branch at checkout time) or an "unreserved" CHECKOUT-NEW (i.e. just merge
back to the original branch on checkin).  One reason why this is better
approach is that this decision tends to persist between sessions, so if
we required it to be explicitly stated on every CHECKOUT, the client
would end up storing this information anyway as some property of a
resource so it can retrieve the value between sessions.  So we might as
well standardize this property so that clients can find this property
on any server that supports this notion.  Finally, this has the advantage
that it keeps the CHECKOUT protocol identical for mutable and immutable
revisions.

   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.

Yes, each of these alternatives is reasonable.  For very common alternatives
like these, I think we should define in WebDAV the workspace property values
that will select them (e.g. DAV:unreserved and DAV:branch-if-necessary).
I'd like to defer the details of this property until I've posted a
description of a "workspace", since that is the resource on which this
property is proposed to live.

Cheers,
Geoff