Re: MKRESOURCE results

jamsden@us.ibm.com
Tue, 21 Dec 1999 16:37:41 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525684E.007C58A9.00@d54mta03.raleigh.ibm.com>
Date: Tue, 21 Dec 1999 16:37:41 -0500
Subject: Re: MKRESOURCE results



I agree with Geoff that the initial revision resulting from MKRESOURCE
isn't that big a deal. It's not really an empty root though as the
properties are initialized. This really brings back up a problem with
MKRESOURCE in that it only initializes part of the state of a resource.
Ideally it would initialize both the properties and contents. So I can live
with c) too.






"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/21/99
11:09:19 AM

Sent by:  ietf-dav-versioning-request@w3.org


To:   ietf-dav-versioning@w3.org
cc:

Subject:  Re: MKRESOURCE results



   From: Tim_Ellison@oti.com (Tim Ellison OTT)

   <geoff>
   I prefer a third alternative: one revision (with default values for all
   properties and an empty body) and one working resource (checked out from
   that revision.  It is the working resource that the PUT or MKRESOURCE is
   applied to.
   </geoff>

   This is going to leave lots of clutter in the version history.

I'm not sure that an empty "root" revision in a revision history
is reasonably classified as "lots of clutter".  And as you say
below, any client that feels this is "clutter" can just hide the
initial empty revision.

   Essentially, every versionable type that was created in a versioned
   collection will have a phantom revision that was never intended to be
   part of the development ancestry.

The empty root revision often comes in very useful when you have
selected a collection revision that has a particular versioned resource,
but you don't want to select any revision of that versioned resource.
The empty root revision effectively captures "the state of that object
before it had any work done to it".

In addition, a variety of operations (such as "compare my contents
to my predecessor") are much simpler to write when there is an
empty initial revision.

Another example is when you are creating a new baseline for an existing
versioned collection, but it is not based on any previous baseline.
With the empty initial revision, you have a reasonable predecessor.

An analogy is that "zero" is a very useful number to have around.

   I can imagine clients trying to
   hide that revision when giving users the option to rollback to an
   earlier state.

I agree.  Which is one reason I don't see any harm (and do see benefits)
in having an empty initial revision.

   Summary of options thus far,
   (a) one revision, no working resource,
   (b) one working resource, no revisions,
   (c) one revision, one working resource,
   (d) change the rules for members of versioned collections, (i.e., no
longer
   have to be versions.)

   I don't like any of them! but I like the spirit of (b).

"d" stands for "disaster" (:-).  In particular, it would require that
    workspaces have "coupled" behavior (i.e. changes in one workspace must
    be made immediately visible to others, thus breaking most distributed
    workspace performance optimizations).
"b" leaves you with "no predecessor of your working resource" and resulting
    strange behavior for "uncheckout" (does the versioned resource
disappear?)
"a" leaves you with an initial revision with meaningless content

So I'm a big fan of "c" (for "correct choice" :-).

Cheers,
Geoff