Next message: jamsden@us.ibm.com: "Re: nested DAV:rsr-or and DAV:rsr-merge"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525685E.0046384D.00@d54mta03.raleigh.ibm.com>
Date: Thu, 6 Jan 2000 07:34:47 -0500
Subject: Re: Removing the "single line of descent" restriction on activities
Geoff,
I'm not sure what you mean by removing the single line of descent
requirement. My understanding was that an activity can only be on one line
of descent. That is, in a branching system, the activity can be thought of
as the name of a branch, and the same activity can't name more than one
branch. This seems like a good thing, and allows us to use activities in
workspace revision selection rules without qualification to get the latest
revision in that activitiy.
I guess I don't see a problem with clients expecting a single activity to
be a single line of descent with a well-defined latest, and multiple
activities being on different lines of descent of different resources. (I'm
not sure what it would mean to have a dependent activity on the same
versioned resource, the workspace will only select one revision, what ever
comes first). I though of needed-activities as a way of collecting related
changes on related resources, not related changes in the same resource.
It is possible to simulate needed-activities to some extent by just
including the activities in the workspace RSR. This isn't as logical, but
it works.
So I don't feel too motivated to change anything and would vote for 0).
Single line of descent does always hold for a single activity. An activity
with needed-activities is not a single activity. Clients will have to be
aware of this.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/05/2000
01:21:24 PM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: Removing the "single line of descent" restriction on activities
Currently, an activity without a DAV:needed-activities property must select
revisions in a single line of descent, while one with a
DAV:needed-activities
property does not. (The DAV:needed-activities property enumerates the
sub-activities that contribute to the logical change of the activity).
I believe that this effectively makes the "single line of descent"
restriction pointless, since clients will need to deal with activities
that do *not* select a single line of descent (since any activity might
have or be given a DAV:needed-activities property).
I see several alternatives:
(0) ignore this issue and leave things as they are now
(1) remove the DAV:needed-activities property
(2) extend the "single line of descent" to apply to the union of
versions in an activity and its needed-activities
(3) remove the "single line of descent" requirement
My thoughts on these alternatives are:
(0) I don't like this alternative (clearly, or I wouldn't have bothered
to send out this message :-). I believe this will be a significant cause
of error for clients and servers that don't realize that
single-line-of-descent
does not always hold.
(1) I think the ability to compose activities out of other future, current,
or prior activities is too important to give up except as the very last
resort.
(2) Since different activities will be worked on independently, I think
it will be computationally infeasible to detect when single line of descent
is violated for multiple activities being changed in distinct workspaces.
(3) I think this is the right way to go. This doesn't actually change
anything from a client's perspective, but ensures that clients don't try
to incorrectly take advantage of a constraint that does not in general
hold.
As always, silence will be taken as permission to make this change to
the next draft of the spec, but will not imply that you will not object
at some later date (:-).
Cheers,
Geoff