Next message: Geoffrey M. Clemm: "draft-ietf-deltav-versioning-05"
Message-ID: <65B141FB11CCD211825700A0C9D609BC033B0702@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
Date: Tue, 27 Jun 2000 10:25:30 -0400
Subject: RE: Versioning TeleConf Agenda, 6/26/00 (Monday) 2pm-3pm EST
Apparently my agenda never made it out to the list ...
just one of those mysteries (:-). Note: the next
conference call will be July 10, since many/most
people are on vacation July 3.
Agenda for today's TeleConf:
- Discuss the proposal to create new activities with CHECKOUT/CHECKIN
rather than with MKACTIVITY
- Discuss Chris' comments on advanced versioning.
Attending the call:
Tim Ellison, Jim Doubek, Jim Amsden, Henry Harbury,
Chris Kaler, Geoff Clemm.
We spent some time on the CHECKOUT/CHECKIN proposal.
There are several motivations for this proposal. One of
them is support simple branching models such as that of
RCS, where a versioned resource has simple activities
called "branches", but a branch is always relative to a
particular versioned resource (i.e. you create a branch
for a particular versioned resource). Another motivation
is that if a server supports multiple repositories, and
an activity in one repository can only be used for checkouts
and checkins in that repository, then a client needs to
let the server know somehow which repository the activity
should be created in. Another motivation is that even if
"multi-repository" activity membership is supported, that
it is more efficient if the activity is located in the
same repository as "most" of its revisions.
The downside of this proposal is that a client could not
create an activity until it had picked at least one versioned
resource to be checked out in that activity.
We did not reach consensus on this proposal, and so will continue
the topic on the mailing list.
Chris' comments:
- Suggest that each advanced versioning concept be preceded by a
description of the use cases that motivate it. There was some
concern that "more" was not necessarily "better" here, but Geoff
agreed to give it a try. One suggestion was to provide this
information in a "rationale" document, rather than putting it
into the protocol document.
- A related proposal was to reorder the semantic sections so that
they are: Workspace, Baseline, Activity, Parallel Dev. and Merging.
This was agreed upon.
- Get rid of the implementation details in the "Merging" definition
in 8.1. Make the rest clearer.
- Add "checkin-branch", "checkout-branch", and "mutable" properties
to a working resource, so that they can be modified by a client.
- Ad a definition of "branch" to the advanced versioning terminology
section (since now it is used in the "DAV:branch-OK" and other properties.
- Modify 10.4.4 so that it says:
If the value is "F", bindings are not captured by a versioned collection
revision.
- Identify which methods support a Workspace header, and whether the href's
returned by the method are relative to the Workspace header. Chris has
some
concerns about the use of a workspace as a collection containing its
versioned
resources, but I didn't follow why this was a problem, so hopefully
Chris will follow-up on this concern to the mailing list.
- Chris will try to post the rest of his issues to the mailing list sometime
in the next two weeks before the next conference call.
Cheers,
Geoff