Re: CHECKIN/CHECKOUT - Branching

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 20 Jan 1999 02:19:58 -0500


Date: Wed, 20 Jan 1999 02:19:58 -0500
Message-Id: <9901200719.AA14171@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: yarong@microsoft.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D51@RED-MSG-59> (message
Subject: Re: CHECKIN/CHECKOUT - Branching


   From: Yaron Goland <yarong@microsoft.com>

   > Branching
   > 
   > When a versioned resource supports immutable-revisions, it is still
   > necessary to support "change".  In particular, there must be some
   > resource that you can name, that will periodically take on new values.
   > For a versioned resource with immutable-revisions, this analogue to a
   > mutable-revision is called a "branch".  Like a mutable-revision, a
   > branch can be checked-out, changed, and then checked-back in.  The tip
   > of the branch then reflects this change.  Also as with mutable
   > revisions, you sometimes want to check out a new branch that is based
   > on (the tip of) an existing branch, which requires another flavor of
   > checkout (i.e. CHECKOUT-NEW).
   > 

   Can you please provide an example of a resource "that you can name, that
   will periodically take on new values" which is an appropriate subject of a
   versioning system? 

Some CM systems implement it as a "floating label".  Others implement it
as "the tip of a branch".  Others implement it as an "unfrozen configuration".
The implementations all differ, but the concept is the same.  There is a
"mutable thing" that you can ask to see in your workspace, and that is
updated when anyone does a "CHECKIN" to that mutable thing.  The fact that
an immutable history is kept for that mutable thing is another characteristic
of immutable-revisions systems, that differentiates them from basic
mutable revision systems.

   Branching, as I understand the term, describes a situation where a versioned
   resource has more than one child. I am having difficulty coming up with a
   compelling scenario that would cause us to treat a checkout that would
   result in a branch any differently than any other checkout. As such I don't
   see the compelling reason for introducing a new method.

It is true that the in practice that the term "branch" is used to mean
both "a child having more than one child" and "a sequence of immutable
revisions on a single line of descent".  After much confusion based on
failing to make this distinction, the versioning design team has adopted
the term "fork" for the first concept, and reserved the term "branch"
for the second.  One of the key distinctions is that a branching system
requires that at most one child of a revision can be on the same "branch"
as its parent.  So you "branch" when you create a child that is not on
the same branch as its parent.  Notice that you can branch without creating
a fork.

Now as for a compelling reason for treating a checkout that would result in
a branch differently from one that does not, one of the commonest version
selection rules is "branch-LATEST", i.e. I would like to see the latest
revision on a particular branch.  If you checkout/in something on that
branch, everyone seeing that branch-LATEST will see your change, while
if you checkout/in something on some new branch (based on that branch)
only people asking to see that new branch-LATEST will see your change.
Notice the identical behavior of "branch-LATEST" and mutable revisions.

Cheers,
Geoff