Re: Discussion Topic: Simple Version Selection and Checkout

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 29 Jan 1999 14:38:35 -0500


Date: Fri, 29 Jan 1999 14:38:35 -0500
Message-Id: <9901291938.AA22561@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: jamsden@us.ibm.com, ietf-dav-versioning@w3.org
In-Reply-To: <015d01be4bac$d8d09900$d0acddcf@yokohama.crystaliz.com>
Subject: Re: Discussion Topic: Simple Version Selection and Checkout

   From: "Sankar Virdhagriswaran" <sv@crystaliz.com>

   >because version selection is almost always done with a floating label
   >or "branch/LATEST", rather than a bunch of special cases for individual
   >resources.  Is it a problem for document-management?

   I cannot speak for document management systems, but for collaboration
   oriented systems, the assumption that selection is done only with labels (am
   I right in understanding what you are saying?) seems too heavy weight.

No, Jim wasn't saying that it can only be done with labels, but rather
that labels and branch/LATEST suffice for many/most situations (he was
trying to be more concrete that just talking about a
"revision-selection-rule").

   Just to clarify, I don't have a problem with the notion of a workspace.
   However, I have a problem with selection based on labels only. Why can't a
   user access and include an arbitrary revision in a workspace?

   Am I missing something?

If you only have a versioned-resource appearing in only one URL in a
workspace, then putting a label on the revision you want to see in
that workspace is a very light-weight, flexible, and interoperable way
of saying so.  Or is there something about labels that concerns you?

The problem arises when you want two different revisions of the same
versioned resource appearing at two different URL's in the same workspace.
In this case, a simple label rule does not suffice (since that would
just pick the same revision at both locations).

So the two choices are: either don't have the same resource appearing
at two different URL's in the *same* workspace (i.e. you have to specify
a different Workspace header to see the other revision), or have some
URL-specific clauses in your revision-selection-rule, that in say:
"At this-URL select revision-X;  At that-URL select revision-Y".

In the first case, life (and yor revision-selection-rule) is simple.
In the second case, life may be no harder, but your revision-selection-rule
gets more complicated).

So bottom line: Does anyone object to saying that you need to pass in
different "Workspace" headers if you want to update different revisions
of a single versioned resource?

Cheers,
Geoff