- From: <Edgar@EdgarSchwarz.de>
- Date: Sat, 6 Jan 2001 17:18:57 -0500
- To: ietf-dav-versioning@w3.org
- Cc: Edgar@EdgarSchwarz.de
After thinking again on what I wrote on lifecyles I find that perhaps my idea wasn't so bad. I'm not sure I want a different resource type with VARIANT-CONTROL. Why not define a version resource as having a state: VersionResource = VersionControlledResource VersionName State State = "working" | "approved" # The names aren't that important. The lifecyle has two states: "working" -> "approved" I really wouldn't like to make a division between document and code versioning. Because code (Speaking of a software release) also brings related documents. Requirements, Design specifications, User manuals ... These documents often are managed like Lisa describes it. This means they are mutable being in a "working" state, go to a "to-be-reviewed" state and finally are in state "approved". Just to give a simple example like you probably will find it in a bigger software project. So by introducing a state property we wouldn't introduce something that's out of the world. You will find lifecycles for documents in every decent Software Configuration Management Plan. Now for code we just do a CHECKIN and set state to "approved" (Skipping "working") For documents we can set state to "working". As long as the author thinks he could still change something he can leave it in this state. And anybody is warned by the state that it can still change. Would that be OK for you Lisa ? OTOH there will be a time when the document version is declared finished. Then just promote it to "approved". Being "approved" also will be required for a version to be usable as a base for delta storage of a successor version or inclusion in a baseline. Cheers, Edgar -- edgar@edgarschwarz.de http://www.edgarschwarz.de * DOSenfreie Zone. Running Native Oberon. * Make it as simple as possible, but not simpler. Albert Einstein
Received on Saturday, 6 January 2001 17:18:58 UTC