W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: long... Re: Working collections

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Wed, 22 Nov 2000 16:36:29 -0500 (EST)
Message-Id: <200011222136.QAA23834@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   I'm still a bit unclear in my head what is actually *at* a history resource.
   Is something there, or is it just a logical entity named by a URI?

Well, that of course is up to the server.  Some implementions will be
an RCS ,v file or and SCCS s. file, and others be records in some database,
probably supplemented with one or more files containing some (possibly
compressed and deltified) representation of the versions' content.

   Bah :-) ... I read the Overwrite as "it is okay if the destination already
   exists; just put the source contents there." All the hullabaloo about
   "delete then copy/move" is a bit overdone in my mind :-)

Well, if you have hard links to that file, you probably will care
a great deal whether or not it was a delete followed by the creation
of a new resource, or just an update of the content of the existing
resource.  And depending on whether or not the parent collection is
checked out (or writeable), one will succeed where the other will fail.

   Back to the question at hand:

Yes, that's always a good thing to get back to eventually (:-).

   But we still have the various problems of setting the targets of the
   selectors in the members. SVN never really deals with targets, it wants to
   work mostly with version resources. Why? Because it copies all the resources
   to the local disk and you edit them there.

If it is going to copy all of the resources to the local disk, it has
to (at least indirectly) tell the server what versions of each resource
it is interested in.  If it just tells the server this via a "SET-TARGET",
then the server knows everything it needs to set up the workspace for that

   When you go to do a commit, it
   needs to work against what it copied (rather than the current target). Thus,
   it refers to the specific version resource that was copied to the client. It
   checks that thing out, makes the changes, and checks it in.

Yes!  Which is one way a workspace is useful, since it keeps track of
what versions the client has downloaded, as opposed to what is currently
in the shared "team" area.

   > To be careful about terminology, it becomes a version selector, not
   > a working resource, since auto-versioning creates version selectors,
   > not working resources.

   Eh? Auto-versioning is related to an automatic CHECKOUT/CHECKIN. I was
   referring to automatically making the new resource version-controlled.
   Further, I create a working resource for the new resource. In the 201
   (Created), I state where the new resource's working resource is located.

Poor choice of words on my part.  I was referring to the "automatic
putting under version control by the server", not the "having the
DAV:auto-version property set" concept.  I'll try to remember to call
the former "auto-version-controlling", and the latter

   1) "When something becomes version-controlled, it becomes a version
      selector." Where is that stated? VERSION-CONTROL creates one, sure.

That's what I meant by "becomes version-controlled", namely, has had
the VERSION-CONTROL operation applied to it.  Auto-version-controlling
behavior by the server is defined to be identical to having the
server apply VERSION-CONTROL to the new resource immediately after
it has been created.

      why can't my PUT create a working resource? (which implies an eventual
      creation of a version, a version history, and a version selector as a
      member of the collection version's extent version selectors)

That would be a significant change to the current definition of PUT and
the definition of a working resource (a working resource just checks out
a version which must be in a version history).  But I think we're OK
there with the "working collection can contain non-versioned resources"
approach, described in my prior message.

   > When you first create a version history, it is given an initial version.
   > When you put an existing (non-versioned) resource under version control,
   > the initial version is a copy of the state of the non-versioned resource.

   That doesn't fully answer the question. The second sentence assumes that I
   have a non-versioned resource. That step isn't possible. I must be able to
   go from the null state to a versioned resource.

If non-version-controlled members of working collections are put under
version control when the working collection is checked in, I believe
that you get what you need (and don't have to go from the null state
to a versioned resource).

   I believe the answer is that a working resource might not have a
   DAV:checked-out property.

That significantly complicates the semantics of a working resource, which
I'd like to avoid.

   How were other people thinking of modelling the creation of a versioned
   resource? Are people assuming that this is a non-atomic creation? (check out
   the parent, put a resource, version-control it, check in the parent; and
   deal with the race between the PUT and the VERSION-CONTROL when the resource
   may not be version-controlled?)

You can just lock the resource to make sure nobody messes with it between
the PUT and the VERSION-CONTROL.  One reason not to allow you to version
control a "null resource" is that servers will often have a very different
way of versioning things like collections from things like files, and
won't let you change from one to the other, and with a null resource,
a server can't guess which one it's going to be.

   This is a great model based on the discussion above. But the target issue
   that you raised still creates problems. The whole reason that I checked out
   a collection version in the first place was to avoid target selectors that
   might not be targeted the way that I need them to be :-)

Remember that a collection version says nothing about the targets
of its members (it just tells you the names and version history of
each member).  So if a target selector is not targeted the way you
want, you just modify the target selector ... checking out and
checking in the collection or any of its members
is independent of what target is selected by a target selector.

Received on Wednesday, 22 November 2000 16:37:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC