Message-ID: <email@example.com> From: "Sankar Virdhagriswaran" <firstname.lastname@example.org> To: "Geoffrey M. Clemm" <email@example.com> Cc: <firstname.lastname@example.org> Date: Wed, 10 Mar 1999 11:24:32 -0500 Subject: Re: IETF Versioning Meetings >configuration. If you version configurations (which I believe you >should), then you use revisions of a configuration to capture the >evolution of that tree. > This is what I was trying to get at. Thanks. >I'm also believe support for "parent" or "nested" activities is essential. >Some other members of the design team or less decided, so feedback pro/con >from the mailing list is encouraged! > > 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'. > >This is a good summary of the need for nested activities. > Repeating myself: I think nested activities are useful for isolating changes in any large web site which has multiple owners (e.g., marketing, engineering, marketing/mark comm, marketing/PR, etc.), multiple rates of change (e.g., today's news vs. spec. sheet), and for large cross functional work groups. At the very least, I would hope that the current design will not make it hard to implement nested activities. >revision-selection rules". That makes less sense to me than >requiring that at *least* a workspace must (always) select the >working resources checked-out into it. > I have not thought about what you are saying. However, I ask a related question (in my mind anyways, I may be confused). How do these selection rules interact with the proposal for URNs. The reason I ask is again to see if the model I have in my mind will work. I see version selection happening because of default or explicit rules of the workspace (as proposed) or by user selection of 'names'. From a cursory understanding of the proposal for URNs that was recently sent out, I thought it allowed for user selection based on 'names'. Am I hoplessly confused? >I believe the answer is "yes", but if you have a dependency conflict model >in mind, please send it in for consideration. The main reason that we have >not dealt with dependency conflicts is that there seems to be very little >commonality in servers today that we could capture in a protocol. > I think you are right w.r.to commonality in servers today. However, it does not stop me from trying ;-). The general idea is to have a set of conditions that need to be met before a 'change' can be successfully applied (change and compound change are the same from this perspective). The conditions assert states in which items need to be for success. Different policy mechanisms can then be implemented to resolve conflicts that arise when a change is applied. The kind of dependency that I described in the example is one 'policy' that makes sure that 'read-write' conflicts are captured by the system. In parallel development with nested activities, this sort of dependency becomes key to manage. There are other policies that one could think of. I hope this all makes sense even though it is pretty abstract.