- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 9 Aug 2001 16:50:10 -0400
- To: luciano.quadraccia@centrelink.gov.au
- Cc: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
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