Message-ID: <email@example.com> From: "Sankar Virdhagriswaran" <firstname.lastname@example.org> To: <email@example.com>, <firstname.lastname@example.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?