Re: IETF Versioning Meetings

Sankar Virdhagriswaran (
Wed, 10 Mar 1999 11:24:32 -0500

Message-ID: <00b001be6b12$7af59210$>
From: "Sankar Virdhagriswaran" <>
To: "Geoffrey M. Clemm" <>
Cc: <>
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
>   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 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.