Yaron Goland (
Tue, 19 Jan 1999 21:02:55 -0800

Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D51@RED-MSG-59>
From: Yaron Goland <>
To: "'Geoffrey M. Clemm'" <>,
Date: Tue, 19 Jan 1999 21:02:55 -0800
Subject: RE: CHECKIN/CHECKOUT - Branching

Welcome to the third in my seemingly endless series of comments on
Geoffrey's proposal.

> 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? 

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.

> From a protocol perspective, this provides a way to unify the worlds
> of mutable and immtable-revisions.  In each world, there is CHECKOUT,
> CHECKOUT-NEW, and CHECKIN, where CHECKOUT modifies an existing
> modifiable entitity, while CHECKOUT-NEW creates a new modifiable
> entity that can be modified in parallel with the original entity.
> CHECKIN is used in either case to return the resource to a 
> readonly state.
> The alternative is to provide THAW/FREEZE operations that can only be
> applied to mutable-revisions, resulting in inoperability between
> servers that support mutable-revisions and servers that support
> immutable-revisions.

I will defer my analysis of the appropriateness of thaw/freeze vs
checkout-new until we make further progress on the more fundamental issues
of the appropriateness of worrying about mutable resource management as well
as the necessity of CHECKOUT-NEW in a versioning system.