Next in thread → Next in month →

RE: [ws-rx-editors] Document titles and revision management

From
Gilbert Pilz <>
Date
2005-10-28T17:26:42+00:00
ID
Thread
RE: [ws-rx-editors] Document titles and revision management
One little comment inline . . .

  

  
  From: Yalcinalp, Umit 
  [mailto:] 
Sent: Friday, October 28, 2005 9:41 
  AM
To: Marc Goodner; Gilbert Pilz; 
  
Subject: RE: [ws-rx-editors] 
  Document titles and revision management

  

  
Not really. I am not sure I explained my point well. Lets 
  me also address your concerns. 

  
 

  
The method I am describing DOES NOT require the tc to see 
  many conflicting revision numbers 01 followed by 23. 

  
 

  
Here is the trick. Lets take a doc revision 
  wsrmp-1.1-spec-wd-01. 

  
 

  
Editors wsrmp-1.1-spec-wd-01 will many revisions of this 
  document, none of them will be marked with a separate number with naming, but 
  its internal revision (hence wsrmp-1.1-spec-wd-01 (01), wsrmp-1.1-spec-wd-01 
  (02), ... wsrmp-1.1-spec-wd-01 (0n). They constitue the changes that editors 
  only make to this document. 

  
 

  
When we decide to publish the last document to the tc 
  this document becomes the version in the tc's list: 

  
 

  
wsrmp-1.1-spec-wd-01 (0n) ==> wsrmp-1.1-spec-wd-01. 
  Since the (0n) version is the last revision, it becomes the TC's version. 
  

  
 

  
The editors now create wsrmp-1.1-spec-wd-02 in the editors tree and start applying incremental 
  changes to it until it gets published to the TC hence wsrmp-1.1-spec-wd-02 (0m) ==> wsrmp-1.1-spec-wd-02 in the TC 
  document workspace. 

  
 

  
So far, the TC is seeing 
  only the result of the increments. 

  
 

  
When the document becomes 
  CD/whatever 

  
 

  
wsrmp-1.1-spec-wd-XX => 
  wsrmp-1.1-spec-cd-XX. 

  
 

  
Hope this makes sense. 
  

  
 

  
We can reflect the XX to 
  match the public view of the revision if you want to make it simpler for 
  external folks to review the document numbers. 
  

  
 

  
This is actually no more work. It helps editors to do 
  their incremental changes, so we can freely work on a branch until the branch 
  gets "published" to the tc. The diffs are between previous numbers anyway. I 
  actually found Kavi to be helpful in this regard since I can manage the 
  revisions and when I publish to the tc. I take the last version and move it to 
  the tc's publication point. It is darn simple to maintain. I also updated the 
  description of the document to contain all the changes that have been applied 
  to the document so it reflects all the changes from the last non-incremental 
  version. This information is what the TC, esp. Paul cares about. 
  

  
 

  
You should also not have a concern about the revisions. 
  The OpenOffice diff facility is really handy about this. You can get a diff 
  between two arbitrary documents. (Thanks to Anish who educated me about this 
  one!) Once a version is published to the TC, it is very easy to generate a 
  diff between the version that is in the TC's document repository and the 
  previous version. Hence, ALL the changes that went into the TC published 
  version (meaning incremental changes) are visible. 

  
 

  
In this manner, the TC is not confused as to why they are 
  getting many "versions". We publish the version when we like to them, announce 
  it and they have it. If they want to see all the versions of a particular 
  version, they can look at the Editor's repository. Nothing is lost, but 
  clutter is avoided. 

  
 

  
The question is how often to send a version to the tc as 
  a wd. We can do this weekly. 

  
 

  
<GP> I remember at 
  the last F2F we decided to "promote" from the editors repository to the TCs 
  repository based on a consensus of when it seemed like we had "enough stuff" 
  to promote. We specifically rejected the idea of promoting on a regular 
  schedule since we didn't want to end up putting out a "wd-0n" and "wd-0n+1" 
  that didn't have any differences between them.  

  
 

  
--umit

  
 

  
Ps. I would not want to devise a semi CVS, but at least 
  this system I believe will work to help both the editors and the tc. 
  

  
 

  
    

    
    From: Marc Goodner 
    [mailto:] 
Sent: Thursday, Oct 27, 2005 9:47 
    PM
To: Gilbert Pilz; 
    
Subject: RE: [ws-rx-editors] 
    Document titles and revision management

    

    

    
OK, now I 
    understand. 

    
 

    
The method as 
    described has many revisions over a wd until piping up to the TC that it’s 
    ready for review. At that point no more revisions would be made against that 
    wd and if any editorial or other changes were needed it would go into 
    wsrmp-1.1-spec-wd-nn +1.

    
 

    
But wouldn’t the 
    editors work on wsrmp-1.1-spec-ed-nn and at 
    some point decide to bring that to the TC’s attention as 
    wsrmp-1.1-spec-wd-nn? So there would be many revisions of the ed-nn version 
    but not of the wd-nn version. I see that going through many ed revisions and 
    then going to a wd version with no revisions would be more work. More 
    importantly its more use of Kavi as well which I certainly see as a bigger 
    pain. So if that sounds like a hassle then don’t worry about it. 
    

    
 

    
My concern was how 
    the TC would view many revisions on a given wd, it seems weird. As long as 
    it doesn’t change once the TC starts reviewing it and pointing to it I don’t 
    see any real problem.

    

    

    
    

    
From: 
    Gilbert Pilz [mailto:] 
Sent: Thursday, October 27, 2005 8:11 
    PM
To: 
    
Subject: RE: [ws-rx-editors] Document 
    titles and revision management

    
 

    
That's not 
    what we agreed to at the last F2F. We agreed that we didn't want bother the 
    group with constantly changing WD versions (Monday wd-03, Tues wd-04 and 
    wd-05, Thu wd-06). We also agreed that we didn't want to create confusion by 
    only showing the group "certain" WDs (wd-05 followed by wd-23) as it would 
    be difficult to follow which WD followed which from the TC's perspective 
    (was wd13 the "next" WD after wd05 or was that wd09?). One of the reasons we 
    wanted CVS was to track multiple revisions of the same WD version. Without 
    CVS we have decided to use Kavi like CVS by maintaining multiple revisions 
    of the same WD version.

    
 

    
- 
    g

    
      
 

      

      
      

      
From: 
      Marc Goodner [mailto:] 
Sent: Thursday, October 27, 2005 6:06 
      PM
To: Gilbert Pilz; 
      
Subject: RE: [ws-rx-editors] Document 
      titles and revision management

      
I think what you 
      want is a title like wsrmp-1.1-spec-wd-02 with no revisions in Kavi at 
      all. When you get to wsrmp-1.1-spec-wd-03 you would then move the old one 
      to the other folder to reduce directory 
      clutter.

      
 

      
I don’t believe 
      there ever should be more than one version of a doc like 
      wsrmp-1.1-spec-wd-nn. I would think any check in would rev the nn. 
      Otherwise how could line numbers stay consistent after you edit on version 
      of wsrmp-1.1-spec-wd-nn and then check in 
      another?

      
 

      
I can see the 
      argument against using Kavi’s versioning and not creating a single title 
      like wsrmp-1.1-spec-wd and then only displaying the nn within the doc (I 
      would assume it should match the Kavi revision number). Note that is how I 
      am managing the issue list during this migration to the stable url. 
      However I can’t imagine someone really wanting revision 05 vs. 07 of that 
      but I definitely see the need for the specs.

      
 

      

      

      
      

      
From: 
      Gilbert Pilz [mailto:] 
Sent: Thursday, October 27, 2005 3:45 
      PM
To: 
      
Subject: [ws-rx-editors] Document 
      titles and revision management

      
 

      

      
Currently in the WS-RX Editors 
      SC area of Kavi we seem to have adopted two methods of title/revision 
      management. The WSRM spec has a single title (WSRM 1.1 Editors Draft) that 
      does not contain any details about versions etc. Under this Kavi title you 
      can find versions of both wsrm-1.1-spec-04 and wsrm-1.1-spec-05 (the fault 
      lies with me, I checked in the first version of wd-05 under the same 
      title).

      

      
 

      

      
The WSRMP spec, on the other 
      hand, is titled "wsrmp-1.1-spec-wd-01.sxw". Under this title you will only 
      find versions of wsrmp-1.1-spec-wd-01. Umit informs me that, when 
      wsrmp-1.1-spec-wd-02 is created, she intends to create a corresponding 
      Kavi title to be used for all versions of wd-02 and so on . . 
      .

      

      
 

      

      
"What's it going to be then, 
      eh?"

      

      
 

      

      
I'm leaning towards Umit's 
      method since it makes it easier to find individual wd-xx versions without 
      having to dig through the history of a single Kavi title. We can keep the 
      "Calendar Documents" folder clean by rolling off old titles into an "Old 
      Titles" folder.

      

      
 

      

      
Comments?

      

      
 

      

      
- 
      g
Next in thread → Next in month →