|
Here is why I will speak in favor of the method I have
devised ;-).
There are three versions of visibility.
Editors
TC
Public Drafts
Lets say we work on a document together. It starts with
xxx-wd-version.sxw in the editors area. This version can be worked on parallelly
with the method that I have used until this version is brought into the tc's
attention. At this point, the tc sees the version, comments on it, etc. At that
point, the editors draft gets labelled version+1 in the editors list, and we
start banging on it again. There may be several revisions of this until it gets
published to the tc again.
Once the wd-someversion gets approved, it gets to change
status and becomes a wd->cd->...
So, pictorially it is sth like this:
Editors: Editors document version (v1, v2, v3, ...,
vn)
TC: Editors.version.vn,
Editors.nextversion.vn...
Public: Selected Editors.version.vn
Hope it makes sense. In this manner, the individual updates
are not exposed to the tc, but to all of us and helps us to use kavi like cvs.
The tc does only care about not small increments but diffs between the versions
they are exposed. I would like to use Kavi for individual updates without
hindering the tc. This is why we have individual repositories anyway.
Apologies for not being methodical about this, since I have
uploaded the versions to the tc as well, but from now on if we use the method I
am proposing, we can use both repositories effectively and can also track
individual changes as well as major drafts.
Comments?
--umit
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:Gilbert.Pilz@bea.com]
Sent: Thursday, October 27, 2005 3:45
PM
To:
ws-rx-editors@lists.oasis-open.org
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.
|