Re: Core versioning scenario and mutability

> This scenario involves only document versioning.  It does not involve
> code versioning.
And here is the problem I think. In code versioning I DON'T want a version
to change.
Probably our problem could be solved if we adopted a lifecyle model for a
version resource like it exists in some tools (E.g. PVCS Dimensions).
A resource version is in a state "initial" after a checkout. In this state
it can still be changed. It can`t be changed any more in following states
(One or more, it depends on the lifecyle you define).
You could use this for documents. For code you would just skip the initial
state and go to e.g. "freezed" and nobody can change it any more.
But I think we can't add lifecyles to WebDAV. That's too complex because
it easily could be extended with roles, ...

> Sometimes, Geoff sends out the URL to a version (e.g. v10) and then
> notices a minor mistake.  Maybe he has to change Jim Whitehead's
> affiliation from UC Irvine to UCSC.  But he's already sent out the URL
> to v10!  Happily, his WebDAV document versioning server supports
> mutability.  Geoff makes the change and doesn't have to send out a new
> email with a new version URL.
The alternative would be to send out the URL to the working resource which
is supposed to become v10. And only after things have settled down he does
a checkin. As long as only Goeff can change the working resource (Or is it
correctly a checked-out-version-controlled-resource :-) in practice it's
not different from a mutable version URL.

> Mutability
> Because of auto-save and user hitting "save" during editing, the server
> MUST NOT create a new version every time the client does a
> PUT/PROPPATCH.  The server must only create a new version when the
> author specifically requests it.  This could be whenever a CHECKOUT is
> performed.
My scenario would be a little different (If WebDAV sees it different
at the moment please tell me)
Only after a CHECKOUT I can change the checked-out-version-controlled-resource
by a "save" which does a PUT/PROPPATCH. And a CHECKOUT doesn't create
a new version, but only a checked-out-version-controlled-resource which can
be modified.


> A client application can then have a single button for
> "create a new version" and when that button is pressed it does a
> CHECKOUT and a CHECKIN sequentially.  Every other change to the document
> is done via PUT and modifies only the latest version.
Agreed, if you say checked-out-version-controlled-resource.

> is not disastrous, but it is a pain: Geoff is likely to get comments on
> v9 that have been fixed in v10, because the user didn't realize what
> version they were looking at.
Agreed, but only a pain for Geoff if the user didn't realize it. Now the
question is, how many such users do we have out there ? 

> possible remedies:
>  - The versioning draft can split into two, one for code-versioning and
> one for document-versioning.
>...
I fear that the cure would be worse than the problem. I see your problem
but also don't see a sensible solution yet.

Like Geoff stated it earlier. Immutable versions are a KEY concept of versioning.

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 Friday, 5 January 2001 15:59:15 UTC