Re: IETF Versioning Meetings
Sankar Virdhagriswaran (sv@crystaliz.com)
Thu, 4 Mar 1999 14:19:48 -0500
Message-ID: <008201be6673$f86d56e0$d0acddcf@yokohama.crystaliz.com>
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
To: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Date: Thu, 4 Mar 1999 14:19:48 -0500
Subject: Re: IETF Versioning Meetings
Jim,
Thank you for the summary. I have inter-leaved some questions/issues. I hope
this is not too late to raise the issues and I also hope that the issues are
more because of my mis-understanding rather than some thing missing in the
semantics being proposed.
>
>A revision of a collection is modified by adding or removing members.
>Changing the contents of a member of a revision of a versioned collection
>does not imply a change to the parent collection.
>
I may be confused about what you are trying to say, however, I wonder if
this assumption is too strong for dependency analysis. If a programmer is
writing code (file A) that is dependent on the specification of the program
(file B) and if both of these are being kept together as a semantically
meaningful collection, then modifying file B or A does impact the semantic
consistency of the collection. Does this make sense?
>Parallel Development with Activities
>
>Resources are checked out in the context of an activity. An activity
>abstracts a set of related changes a user is making to versioned resources.
>Each activity represents a parallel thread of development. Servers that
>don't support parallel development effectively only support one, default
>activity.
Are nesting of activities allowed? If not this model is too restrictive for
web site development and deployment. Furthermore, if nested activities are
allowed then are 'continuation' of activities after intermeidate submissions
are made allowed?
There are two fundamental notions here. Change and compound change. It
sounds like your description covers the 'change' concept, it does not cover
the 'compound change'.
>A workspace contains a current activity and a revision selection rule.
I don't understand the semantics of 'contained'. The way I think about it
each activity is associated with a workspace and each workspace has
selection rules. Am I missing something.
>Revisions are selected using the following rules in order: 1) if there is a
>checked out revision, then it is selected. else 2) if there is a revision
>that is checked in under the current activity, then the latest revision in
>this activity is selected, else 3) the workspace revision selection rule is
>applied to select the revision. If there is no matching revision, then a
>resource not found status is returned. This rule is applied to collections
>to select the revision that determines their member versioned resources,
>and to other resource to determine the revision containing their contents.
>
Could you provide some rationale for why the ordering? I am confused. I
would think that the simplest case (and hence the default case) would be to
allow users to checkout named (and not labeled) revisions in the context of
a workspace and there is no 'view rule' processing required. Don't you
thinking processing of view rules should be followed after this. Maybe that
is what you are saying, but just wanted to make sure.
>Versioned Collections
>
>A collection contains a set of members. For versioned collections, the
>members are versioned resources, not particular revisions. To add or remove
I assume versioned collections can contain other collections. Is this
assumption correct?
>the current workspace specify revisions that are on different
>lines-of-descent, and a potential merge conflict exists and is included in
>the merge conflict report.
>
How are dependency conflicts captured in this model? Are they excluded in
the current thinking?