RE: A different perspective on versioning cf DeltaV

   From: luciano.quadraccia@centrelink.gov.au

   The reason why I am writing to you is that we have implemented a
   version control system for our mainframe software, where our
   versioning model has many similarities to DeltaV, but differs
   significantly in the emphasis it gives to releases.  If possible I
   would like to explore with you the advantages of our model, and I
   am very interested in your opinion and whether you believe DeltaV
   caters for our requirements.

I believe the answer is yes, and will try to indicate below how your
system could be modeled with the DeltaV protocol.  I'll CC this to
the DeltaV mailing list, since it provides a good example of how
DeltaV can be used to expose a variety of versioning models.

   For most
   changes, the full development cycle takes 3-6 months from initial
   analysis to implementation.

I will assume that by "implementation", you mean what I would consider
"deployment" (i.e. deploying the system for use by the end users).
Normally, I would use "implementation" to mean "writing the code",
but we'll use your definition for this message.

   Most of these changes have legislated
   fixed implementation dates.  This means that at any point in time
   there will be many software modules that have been changed and are
   scheduled to be implemented with different releases.

In DeltaV, your "release" would be modelled as an "activity".
In addition, each release would have a set of labels, with one label for
each QA level.  For example, for release A you would have
labels: RelA-fully-tested, RelA-barely-tested, RelA-not-tested.

   It is not uncommon for 20 different releases to be defined and
   active simultaneously, and it is possible that a module has to be
   changed within a release and across the releases, and many
   development teams could easily be developing changes simultaneously
   for 3 or more releases.

I assume "changed within a release" means the change is only made
in that release, while "changed across releases" means the change is
made in that release and all (or some selected) subsequent releases.

   Centrelinks' versioning system: (I have tried to use the same
   terminology you use, but please excuse me if, because of my limited
   understanding of DeltaV, I use it incorrectly.)

   A release is the set of all revisions that are scheduled to be
   implemented together at a particular date/time.

You would add the "implementation-date" as a property on the activity
that corresponds to the release.  Because of the way you use QA levels,
you would select the versions for a release with labels, rather than
defining a single line of descent with the activity.

   Centrelink's main difference with DeltaV is that our versioning
   model provides specific support for the release.  In particular,
   our version control system, loosely called the Centrelink
   Repository, maintains a version tree of releases, whereas DeltaV
   maintains a version tree for each versionable resource.

You would model this release tree in DeltaV as a "preceding-release"
property on the activities that you use to model releases.

   I understand the concept of releases can be implemented in DeltaV
   by the use of labels.  And I understand that there are facilities
   in DeltaV for the label to be moved automatically from revision to
   revision.  However, the whole approach seems to be adhoc, requiring
   the developer to do lots of bookkeeping so as to be sure of the
   exact role for each revision.  This is because from DeltaV's point
   of view there is no differentiation between the revisions, and each
   is given equivalent level of importance.  Centrelink's approach
   requires much less effort for the developer.

A users gesture that says "set this QA level for this version" would
be mapped into a "set this label for this version".  So a developer
would not see anything different when DeltaV was used to communicate
between your client and your server.

   Centrelink's system is aware of which revisions have been
   implemented and are in production, the QA level achieved by each
   revision (eg fully tested, barely tested, not tested), and the
   release in which each revision belongs.

There would be a label for each QA level and release, e.g. one
"RelA-fully-tested", "RelA-barely-tested", "RelA-not-tested",
"RelB-fully-tested", etc.

   Production revisions
   cannot be changed: they can only be superceded by revisions which
   have attained the highest QA level.

DeltaV versions can never changed, but labels can be reassigned,
which provides the "supercedes" functionality.

   This can happen only when a
   release is implemented: all revisions at the highest QA level
   replace the production revisions.

This would be done by assigning the appropriate labels to those
revisions.

   If for that release revisions
   exist at any other QA level then the implementation is not allowed
   to proceed.

This restriction is one that is not required by DeltaV, but certainly
could be enforced by your server.

   Earlier production revisions are no longer tracked by
   the system (though copies are placed in an archive for historical
   reasons, with sufficient metadata that describes the ancestry of
   each).

DeltaV does not differentiate between "tracked" and "archived"
versions, but your server could automatically archive the
appropriate versions.

   Similarly, at each QA level, a revision cannot be changed
   directly except for revisions at the lowest possible level, "not
   tested".

In DeltaV, no version can be changed, but I believe what you want
here is to indicate that a different version is at a particular
QA state for a particular release, and that can certainly be done
by moving the appropriate label each time the QA state is changed,
or each time a version is "moved" to a new release.

   Thus, for each versionable resource, the system is
   tracking only the latest revision at each QA level, for each
   release.

In DeltaV, this is modeled as only labeling the latest
version that has a given QA level in a given release.
For example, when the user indicates that a new version
is fully-tested for RelA, the RelA-fully-tested label is
moved to that version.

   This makes it very simple for developers, and there is
   never any confusion about which revision the person should be
   working on.  Fundamentally we implemented a simple rule (others
   might wish to vary the rule, but the concept is the same), where,
   in a particular release the only revision that can be edited is:

	- the one at the lowest QA level in that release, or
	- if there is none, then
	     - the one that has reached the maximum possible QA level and
	     -  is in the release closest to and is an ancestor of the
current
   release in the release tree, or
	- if none, then the production revision.

In DeltaV, this would be modeled as a restriction on what version
can be checked out.  This is not required by DeltaV, but could
certainly be enforced by your server.

   From that point on, the system is equivalent to DeltaV, so that a
   change in an earlier release effectively causes a branch for a
   revision in the later release, labelling it "broken", later forcing
   a merge between the two revisions.

Yes.  DeltaV doesn't require you to explicitly mark a version as
"broken" since this information is available from the version history,
but you certainly could introduce a "broken" property for this
(it would be a property, not a label, since a label can only select
one version from a version history, while multiple versions in a
version history can be "broken").

   The developer logs in to the version control system and selects the
   release to work in.  (The system remembers this in the user's
   profile).  All changes the developer makes are automatically
   labelled (in DeltaV terms) as "not tested".

Actually, for release A, they would need to be labeled
"RelA-not-tested", not just "not-tested", since each release can
select a different version as its "not-tested" version.

   When the developer is
   satisfied with the changes and has done some unit testing, the
   developer, or the supervisor, can promote the module to the next QA
   level "barely tested".  And the same is repeated for the next QA
   level (we have 3 QA levels, and occasionally there is talk of
   creating a 4th).  This seems equivalent to assigning labels in
   DeltaV, but in Centrelink this is done in the context of changes to
   QA levels, and always within the same release.

The "release context" needs to be included in the label name,
e.g. "RelA-not-tested".

   The  developer  can  also move revisions from one release to another.

This would be modeled in DeltaV by assigning a different label to the
same version, e.g. you move a version to the RelY release by adding a
RelY-not-tested label to it.

   Also the administrator can move a whole release from one place in
   the version tree to another.

This is done by using the Depth header on the LABEL request, so that
you can label all revisions in a release with the appropriate label
for the new release.

   The system applies the same rules as when a change is made to a
   revision in an earlier release, so when this move happens the
   system marks as "broken" the appropriate revisions in descendent
   releases.

As above, with DeltaV, there is no need to mark versions as "broken",
since the version tree tells you whether or not a merge is required,
but adding an explicit "broken" property would be fine.

   Diagram:  Version  history of foo.html.   Say that at a particular point
in
   time there are 7 revisions as shown in the diagram.

			 Revision name, for QA level reached:
      Release name:    Fully tested   barely tested   not tested
      =============    ============   =============   ==========
      Production        V1
	 |               |
	 |               |
      A: June 2001      V2--------------V3--------------V4
	 |               |
	 |               |
      B: Sept 2001      V5--------------V6--------------V7

This is not what DeltaV would call a version history.  In DeltaV,
the version "history" contains a record of which version was created
from which other version.  What you describe above is a "quality
level" tree, showing which version is "better" than which other
version.  These relationships would be captured by the
labels, and not be what DeltaV calls the "version history".

   This  diagram  shows that revision V2 is a direct descendant of V1, V3 is
a
   descendant of V2, V4 is a descendant of V3, V5 is a descendant of V2.
   Each of the following scenarios is based on this initial state.

   Scenario 1: A user logged in to release B can only edit V7.  The
   changes are made in place and the earlier edition of V7 is
   destroyed.

Since you identify a version by a release-QAlevel label, it would
appear to a user that the older version is gone when the label is
moved.  If you really "destroy" that earlier version (as opposed to
archiving it), then your server would be required to update the
predecessor/successor relationships that referenced the destroyed
version.

   If the user thinks V7 is worth retaining, he would
   promote it to "barely tested", thereby replacing V6 (which is
   copied to the archive), and the changed revision would be V8,

In DeltaV, "replace" here just means moving the RelB-barely-tested
label from V6 to V7.  Your server can automatically archive V6, if it
wishes to do so.

   so the diagram would look like:

      Production        V1
	 |               |
	 |               |
      A: June 2001      V2--------------V3--------------V4
	 |               |
	 |               |
      B: Sept 2001      V5--------------V7--------------V8

   This demonstrates that the system is only tracking the "tip" at
   each QA level (though, with some effort, the user can extract more
   information from the archive).

This is what allows you to use DeltaV labels to model your system.

   If  the  user  deems the V8 changes to be a failure he can
   delete it and revert to using V7.  Similarly if V7 fails, he can go back
to
   V5.   We  found  this  model to work very well and it is extremely rare
for
   someone to have to go to the archive to pull out a different revision.

"Going back" would be modeled in DeltaV by moving the appropriate label.

   Scenario  2: If instead V5, V6 and V7 do not exist yet, a user logged in
to
   release  B  can  only edit V2, and the revised module would be labelled
Not
   Tested.  So we get:

      Production        V1
	 |               |
	 |               |
      A: June 2001      V2--------------V3--------------V4
	 |               |
	 |               |
      B: Sept 2001       -------------------------------V5

   Scenario  3:  If a user promotes V3 to "fully tested", then the new
diagram
   is:

      Production        V1
	 |               |
	 |               |
      A: June 2001      V3------------------------------V4
	 |               |
	 |               |
      B: Sept 2001      V5-broken-------V6-broken-------V7-broken

   Note  that  V2  has been archived, and that V5, V6 and V7 have been
labeled
   "broken" as they are not descendants of V3.

In DeltaV, the predecessor relationship would tell you whether or not
a particular version is "broken", i.e. a version is broken if
fully-tested version from the preceding release is not an ancestor
of the versions in the release.

   Scenario  4:  If  release  A  slips  to October, then this is equivalent
to
   moving  Release B and inserting it in the tree in front of Release A.
This
   causes  the  revisions in Release A to be marked as broken. The diagram
now
   is:

      Production        V1
	 |               |
	 |               |
      B: Sept 2001      V5--------------V7--------------V8
	 |               |
	 |               |
      A: Oct 2001       V2-broken-------V3-broken-------V4-broken

The same rule from above applies here, namely that a version is "broken"
if the fully-tested version from the preceding release is not an
ancestor of the versions in the release.

   I hope I have described enough to give you a feeling for our model.
   We believe this same model should work equally well for the web,
   where we fear we could end up having hundreds of thousands of
   modules.  Our system is already capable of handling changes to tens
   of thousands of modules, whereas we suspect that the effort to
   maintain the individual version trees for each resource to be
   overwhelming at our current rate of change.

The only overhead that DeltaV would place is that it would require
your server to maintain the DAV:predessor-set for a version, which
does not appear to be something you do today.  This is actually
very easy to do (i.e. you only update it when you create or delete
a version), so I don't think it would be hard for you to maintain
this information.

   Sometimes it is put to me that Centrelink is different, and its
   requirements are different, so that our model is not applicable to
   other organisations.  However I don't agree with that, as I believe
   our model is applicable anywhere there are large numbers of items
   that change and where the changes have interrelationships so that
   certain changes have to be synchronised, or at least released in a
   particular sequence.  Further, I believe that the web is making
   this requirement stronger, with more frequent incremental releases,
   thereby increasing the need for a versioning model similar to ours.

There are several versioning systems that provide a model similar to
this (especially the systems that are based on relational databases,
since the "release/QA-level" model maps easily into a couple of 
columns in the relational database).  There are alternative models
that some users find either simpler or more powerful, but DeltaV
was designed to support a variety of versioning models, including
ones like the CentreLink model.

Cheers,
Geoff

Received on Thursday, 9 August 2001 16:42:22 UTC