Re[2]: Baby steps

     I think it would help the discussion to distinguish between two 
     different concepts: revisions and versions.  I won't pretend formal 
     definitions, just brief characteristics and examples distinguishing 
     the two.  While my comments may indicate a specific implementation, 
     please take these as examples...
     
     * Revisions are automatically generated and assigned names such as 
     1.3, 1.2.1.4, etc. when a versioned item is modified, say by a CHECKIN 
     operation.
     * Revisions are immutable, both their name and their data, but they 
     may have mutable metadata, such as labels or comment fields.
     * A sequence of revisions represent changes over time of a single 
     versioned item.
     
     * A version on the other hand is determined by a human and named by a 
     human.  A CHECKIN operation only changes the version if the human 
     specifies it so via a parameter, etc..
     * Versions can be mutable, or immutable.  Normally, versions are 
     mutable for a time, and then frozen.  But frozen versions can be 
     thawed to make modifications if needed.
     * Version labels are used to access items with an application-specific 
     semantic intention, e.g.. "Latest version of Release 5", or "Currently 
     Shipping Version", etc.
     * A revision name provides no application-specific semantic value.
     
     There is no conflict here, revisions and versions are both needed to 
     support configuration management (for example).  Versions can be (and 
     have been) implemented using floating and fixed labels on top of 
     revisions.  Other models can also be used.
     
     So the question I hear Bruce asking is "Can WebDAV allow implementors 
     to support Versions, but make Revisions optional"?
     
     I think the answer is yes.  However, I also believe that WebDAV needs 
     to model both Versions and Revisions explicitly in order to pull this 
     off.  A client needs to be able to find out if the server supports 
     revisioning and how that revisioning will behave during a CHECKIN, for 
     example.
     
     I agree with many previous comments that Revision support (of some 
     sort) is an absolute requirement for doing configuration management.  
     Versioning alone is often not sufficient, even for legal reasons.  
     However, a pure versioning system does have collaborative value, 
     especially when combined with locking.
     
     --Sarge
     
______________________________ Reply Separator _________________________________
Subject: Re: Baby steps
Author:  "Bruce Cragun" <BCragun.ORM2-1.OREM2@gw.novell.com> at SMTPPOST 
Date:    8/7/98 11:34 AM
     
     
I'm not saying there aren't valid reasons for forcing new versions, just that 
this should be up to the server and not the spec.  I know we aren't the only 
document management system that doesn't force it, and having the spec require 
this would break the model of any DMS out there that currently leaves it to the 
user.
     
As we've asked many, many customers about this, only about 20% want forced 
automatic versioning.  Another 50% or so would like the *option*.  In many 
cases, administrators are very much against the automatic versioning because of 
the disk space required to maintain such a system (unless you only save diffs, 
which isn't the case with us).
     
So let me propose this, and anyone can tell me why this won't work:  The spec 
should leave it up to the server to force or not force.  There would be a method
of discovery for clients to determine what the server's rule is.
     
>>> John Stracke <francis@netscape.com> 08/07 11:27 AM >>> 
Bruce Cragun wrote:
     
> There are two scenarios.  First, which I believe is VERY common, is to allow 
me to edit a leaf node and have the changes go back into that same version.
     
Mmm, yeah.  Personally, though, I'd say that this approach is suboptimal in many
cases--for example, if multiple users have access to that leaf node, then you 
run the risk of lost updates, and you can't tell who made every change.  I'd 
prefer to see stuff like this done via a scratch area.
     
> The second scenario is to allow me to edit a non-leaf node and save those 
changes back into that node.
     
EvilNastyIcky!
     
One major advantage of versioning is that it lets you do audits.  If you're 
versioning your source code, and somebody complains that it breaks only when 
they've got their username set to "John Smith", you can go back in the code and 
find out that Joe Blow put in a poison easter egg because he hated somebody 
named John Smith.  If you're versioning your Web site, and somebody accuses you 
of having put child porn on it, you can check back at every version that's ever 
existed and prove that you didn't.  These capabilities break down if you can 
edit non-leaf nodes.  I take your point about not restricting the servers too 
much; but this sort of functionality is so vital that I would prefer to make 
sure the protocol can't be asked to break it.
     
> Right now I would have versions for all previous years, 1998, and the new one 
for the upcoming year 1999.  If a mistake is found in our 1998 handbook, I would
like to fix it in-place.
     
That's what branching is for.
     
--
/====================================================================\ 
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported | 
|Software Retrophrenologist|=========================================| 
|Netscape Comm. Corp.      | Veni, Vidi, Ridi:                       | 
|francis@netscape.com      |  I came, I saw, I mocked.               | 
\====================================================================/ 
New area code for work number: 650

Received on Saturday, 8 August 1998 17:49:36 UTC