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.