W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Confusion about what a VCR is

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 12 Jun 2001 17:36:23 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E246A@SUS-MA1IT01>
To: DeltaV <ietf-dav-versioning@w3.org>
   From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]

   The only time this could cause a race condition is if you allow
   mutable versions, which I think Geoff tends to block out of his
   brain because they are so yucky, and that's basically what you get
   for using them.  Which begs the question of why we don't just kill
   that feature in the spec...

Mutable versions have not existed for a while.  They were replaced
with "variants", and then the variant feature got deferred to
a separate spec.  So mutable versions in their pernicious form
are dead and gone.  Mutable versions in their cleaned up useful
form (variants) are alive but on hold.

But Eric's basic question still applies: why do you want to
label a version-controlled resource, rather than a version?
This would require you to define a bunch of potentially 
complicated semantics ... i.e. are two version-controlled
resources from the same version history allowed to use
the same label?  If so, then you'd have to define the
label application semantics at CHECKIN time (replace, or
fail if already present).  If not, then before it could 
apply a label, a server would have to query every version
controlled resource associated with that version history
(some of which may be on disconnected servers) in order to
see if it could apply a label or not.  Neither of these
alternatives are especially palatable, so we'd need a pretty
compelling use case to allow labels to be applied to the
version-controlled resource itself.


   > From: Lisa Dusseault
   > I keep having to revise my model of what a Version-Controlled
   > Resource is, or represents, and I think today I finally figured
   > out where some of the source of my confusion lies.  The early
   > part of the spec is quite clear that the VCR and its latest
   > checked-in version are different things:
   > "when a method is applied to a version-controlled resource, it is only
   > applied to that version-controlled resource, and is not applied to the
   > version resource that is currently identified by the
   > DAV:checked-in property
   > of that version-controlled resource.  Although the content and dead
   > properties of a checked-in version-controlled resource are required to
   > the same as those of its current DAV:checked-in version..."
   > But the LABEL method takes a different approach:
   > "If a LABEL request is applied to a version-controlled resource, the
   > operation MUST be applied to the DAV:checked-in version of that
   > version-controlled resource."
   > For the LABEL method, the VCR is treated as if it is a link to the
   > latest-checked-in version, even though elsewhere that's not the case.
   > I think this is wrong; a PROPPATCH applied to the VCR changes the
   > properties
   > of the VCR and not the latest checked-in version.  LABEL should behave
   > same way.
   > If LABEL behaviour is not changed, then there's no way of applying a
   > before checking in.  E.g. I can't label the version I'm about to
   > check in; I
   > have to wait until I've completed the checkin before sending the LABEL
   > request.
   > lisa
Received on Tuesday, 12 June 2001 17:31:00 UTC

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