Next message: Greg Stein: "review of -06 draft"
Message-ID: <398146D10000182D@mail0.mailsender.net>
Date: Thu, 3 Aug 2000 08:41:15 -0400
From: "Tim Ellison" <tim@peir.com>
To: "Delta-V" <ietf-dav-versioning@w3.org>
Subject: Minutes from IETF breakout meeting, 2-Aug-00
Minutes from the Delta-V Breakout Meeting
held 9am - 3pm Wednesday 2 Aug 2000, IETF Pittsburg, PA
Attendees:
Jim Amsden (Chair)
Geoff Clemm
Jim Doubek
Tim Ellison
Henry Harbury
Chris Kaler
Eric Sedlar
Rick Smith
Jim Whitehead
- Meeting opened at 9am.
- Restated that the versioned baseline property on a collection is not restricted
to a
workspace. The server is free to decide which collections can be baselined.
- BASELINE method applied to a colelction (versioned or unversioned) creates
a versioned
baseline property on the collection for remembering the baselines (i.e.
baseline history
resource) of the collection.
Clients can CHECKOUT the URL found in the property (i.e. checkout the baseline),
maybe
PROPPATCH the resulting working resource etc. The properties of the resource
are alive e.g.
the revision set. It is legal to MERGE a checked out baseline into a workspace.
- Discussion of why MERGE will not support adding back in missing members
- the only
meaningful implementation would do 'the pilot thing' and duplicate renames,
and this is
undesirable.
- The user readable name for a baseline is the URL of the collection for
which this is a
baseline.
- Described using baselines as a component of reuse. Steps would be (1)
create a baseline
of a collection, (2) create a second collection resource using BASELINE
(c.f. VERSION) to
create the resource and pass in the history reference to the baseline of
step (1). You now
have two distinct collections that share the same history resource and have
initialized the
second to the baselined state of the first.
- Choose terminology to distinguish between the verb and noun "baseline",
i.e. bringing
something under baseline control (c.f. version control), and teh resource
that is created.
Possibility is to think of 'baseline is to version as snapshot is to revision',
alternatives
include baselined resource c.f. versioned resource, etc.
- Nested baselines may be implemented as baselines containing references
to other baselines,
but left for servers to implement however they choose. Not defining semantics
of nesting.
- Cross workspace BINDings will introduce lots of complexities are are unlikely
to be
implemented by most people.
- Reminder to update the protocol doc to reflect the multiple activities
for a given
revision. Recap of reasons for change.
- Discussion of change sets and branching and how they are modelled using
activities.
- Current activity in a workspace is still useful, and will remain a single
activity; but he
activities argument for CHECKIN and CHECKOUT will take a set, and the activity
property of a
revision becomes an 'activity-set'.
- 8.1 MERGING should be a declarative definition of merging rather than
an explaination of
the algorithm. Chris K. to submit alternative.
- 8.1 prefer to use the work 'fork' rather than 'branch'.
- Should make explicit in the protocol document how to use activities for
named branches.
Should be in the motivation section (or separate motivation document?).
Include treatment
of changesets, branches, and activities.
- Discussion of using MERGE, and how to detect no conflicts compared to
a conflict that the
server has resolved by auto-merging content. Auto-merge only created working
resources. A
new (boolean) property will be added to the working resource to indicate
that the merge must
be reviewed.
- Add an option to MERGE to indicate that the server should not attempt
auto-merge. Noted
that auto-merge will often only be attempted for directories/collections.
- 9.5 VERSIONED COLLECTIONS should describe that private bindings are always
bindings to
unversioned resources -- add the 'file.o' example and/or picture. Get rid
of teh
public/private concepts and re-phrase in terms of versioned and unversioned
resources.
- 9.3 ACTIVITY replace 'project' with 'work effort' and decribe situation
as a work
management policy rather than protocol restrictions.
- Discussion of whether to re-introduce "latest" as a label functor. Take
to the list.
- Discussion of versioned collections and the implications of a collection
containing
history resources and baselines.
- Break for lunch
- Discussion of introducing a structured resource type property that indicated
the
attributes of the resource, and leaving resource-type for downlevel clients.
- 12.9 CHECKOUT remove the postcondition that the response location must
be the combination
of the workspace URL + request URL. Add a new postcondition that it must
be true that the
workspace URL + request URL will identify the working resource.
- Discussion of introducing a 'revision id' as a live property of a revision
that is
generated by the server according to some pattern (not necessarily client
defined) so that
it is (slightly?) more readable by the client than the revision URL.
Compromise is that revision id is a distinguished label whose value is also
stored in the
revision id property. Group did not agree.
Server should fail LABEL/delete requests against that label. If the property
is empty, then
the server does not support the revision id concept.
- Further compromise that the revisions have a property, whose value is
not required to be
in the label namespace, but is guaranteed to be unique across all revisions
of the versioned
resoruce. Call it "revision name". Assigned by the server on CHECKIN,
in a format defined
by the server. Cannot be used in a Target-Selector to select the revision.
Likely use is
for 1.1.x style naming, dates, sequence numbers, etc. esp. in DMS. Group
agreed.
- Action Chris K.: Inspect current state of WebFolders to see if they can
cope with
structured values in resource type so this property can be used instead
of creating a new
property. Extending the current property would be preferable.
- 10.3.3 requires further explaination about 'reserved-ness'. Extend the
definition,
covering activities and linear line of descent dearture from seantics until
CHECKIN,
provided for flexibility.
- 10.3.4 expand these sections for clarity.
- 12.x MKCOL has disappeared from existing methods descriptions -- check
to see if it should
be added back in.
- 12.10 requires 'new' XML element definition and (href, new) -> (href |
new) in additional
marshaling.
- 16 LABEL method returns labels, not PROPFIND.
- 12.8 VERSION requires further clarification in the initial paragraph.
- Discussed whether labels should be made accessible via a (live) property
so that they can
be discovered using PROPFIND.
- Winding up meeting, outstanding Chris K. issues that were not discussed:
'Nested' workspaces (parent relationship).
Version method passing in the history resource reference.
Checkin/hidden - change terminology.
Cross-workspace MERGE i.e., workspace to workspace merging.
Advanced reports: requires rationale for them and description of when optional
for advanced
compliance.
Repository report DTD implies not all can be asked/retrieved as a set (one
round trip) e.g.,
wksp & activities
LOCK in core versioning requires further discussion.
- Meeting closed at 3:11pm
TPE