Re: CHECKIN/CHECKOUT - Branching
Yaron Goland (yarong@microsoft.com)
Tue, 19 Jan 1999 21:02:55 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D51@RED-MSG-59>
From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
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.
Yaron