Re: Branching Scenarios
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 21 Feb 1999 13:37:46 -0500
Date: Sun, 21 Feb 1999 13:37:46 -0500
Message-Id: <9902211837.AA03560@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Bradley_Sergeant@intersolv.com
Cc: ietf-dav-versioning@w3.org, jamsden@us.ibm.com
In-Reply-To: <0028AFBF.@intersolv.com> (Bradley_Sergeant@intersolv.com)
Subject: Re: Branching Scenarios
Suppose we defined a DAV:branch property that can be assigned to an activity.
This is just a way for a client to say what "branch" they want products of
that activity to go on. A server can just ignore this property, if it doesn't
support or isn't interested in branches (e.g. a change-set system).
Let's see how this plays out against Brad's scenarios:
From: Bradley_Sergeant@intersolv.com
Case 1: Version V1 of a product ZOO has reached its feature complete
milestone (FC), which for this project means it has all its intended
features, but still has bugs to be fixed. At this point some
developers will continue fixing bugs in version V1, but others will
move on to work on the next version (V2). The V1 code is on the
mainline.
So V1 activities had their DAV:branch property set to "mainline".
Because further changes to V1 are intended to be minimized
and the V2 work is a natural evolution of the V1 work, V2 work will
continue on the mainline.
So V2 activities will have their DAV:branch property set to "mainline".
Also, it is important that all bug fixes
for V1 also be immediately reflected in the V2 work. So V1 bug fixes
also will be reflected on the mainline. If a resource needs to be
changed for a V1 fix and it has already been fixed modified on the
mainline for V2, then the V1 change is made on a branch and also on
the mainline. Otherwise, if no V2 changes have yet been made to the
resource the V1 change is only made on the mainline. Thus the V2
version of ZOO is just the tip of the mainline, whereas the V1 version
must be obtained from a fixed configuration (via a fixed label, or
whatever mechanism is used) and this configuration must be updated
with each bug fix to V1.
A simple approach is to just set the DAV:branch of V1 bug fix
activities to be "V1-bug-fix", and then require that all V1 bug fix
activites be merged to the mainline. Then the RSR for V2 is just
LATEST(mainline)
and the RSR for V1 is just
LATEST(V1-bug-fix) else V1-Config
This produces the effect you want, but isn't *identical* to the branching
you describe above. To produce something identical, you could just add
another property, say DAV:secondary-branch. Then you would set the
DAV:branch of a V1 bug fix to be "mainline" and the DAV:secondary-branch
to be "V1-bug-fix". Your server would put things on the DAV:branch if it
could, and otherwise put it on the DAV:secondary-branch. In this case,
the RSR for V1 is more complicated (to capture the changes you made on the
mainline that are for V1). Because of the resulting complication in the
V1 RSR, I'd recommend the first approach, but that's up to the user/client.
Case 2: Version V1 of product ZOO has been released and version V2
development is well underway. A key customer has contracted to have a
specific enhancement made to V1 specifically for them, the resulting
version is referred to as V1-A. The V1-A enhancement is superseded by
different features that will be available with the V2 release, but the
customer does not wish to wait for V2 to complete. All work on V1-A
will not be used in V2. Therefore all V1-A changes are made on
branches newly created just for V1-A.
Just set the DAV:branch property of V1-A activities to be the "V1-A".
I don't see how this can be done without some indication being given
as to which branching policy is desired for each Activity.
Agreed.
Such an
indication could be in the form of a property on the Activity or an
option in the creation of the activity.
We've got a fine extensibility mechanism in the form of properties ...
I say, use it. What else would the "option on creation" map to? You
could try to bundle all this into the "resource-type" property, but I
see no reason to do so.
Alternatively or in addition,
an administrator might specify which branching policies were allowed
for a set of resources. The indication of which policy to use could
be abstract and general, e.g. Principle vs. Supporting activity. Or
the indication could be an implementation specific property. A third
idea would be to see if a few specific types of activities could be
defined to meet known needs and leave the door open for adding new
ones later.
I believe there are just two suggestions here: have this additional information
stored in the resource-type, or store it in new properties. The latter seems
far more flexible, with no disadvantages, so I'd vote for that.
None of these choices fills me with glee. I'm probably missing
something. Help me out.
What's wrong with a couple of conventional properties, that allow a client
to store a choice in a standard place accessible by interested clients and
servers?
Cheers,
Geoff