forking on checkin vs. on checkout

Sean Shapira (sds@jazzie.com)
Wed, 20 Jan 1999 05:04:47 -0800 (PST)


Message-Id: <m102xJQ-000OW3C@jazzie.com>
From: sds@jazzie.com (Sean Shapira)
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm)
Date: Wed, 20 Jan 1999 05:04:47 -0800 (PST)
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <9901200622.AA14143@tantalum> from "Geoffrey M. Clemm" at Jan 20, 99 01:22:27 am
Subject: forking on checkin vs. on checkout

Hello Geoff and the rest of the versioning design team.  Thanks 
for doing a great job proposing a workable versioning model!

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.

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.

-- 
Sean Shapira         sds@jazzie.com         +1 206 443 2028
               Serving the Net since 1990.