RE: Version-controlled collection resources - I am still missing something

"Clemm, Geoff" <gclemm@rational.com> wrote:

>    From: Alan Kent [mailto:ajk@mds.rmit.edu.au]
>
>    But I agree that the current semantics seem quite
>    inefficient. 99% of the time, getting the first
>    version in a series will not be what is wanted.
>
> There may be some confusion here between what is done on
> the server and what is done on the client.  A server does
> not need to "get" any version, since an efficient
> implementation will just set the DAV:checked-in property
> of the VCR, and not make an actual copy of the content and
> dead properties of the version.

Agreed.

> Also, remember that the only time this "pick the initial
> version" functionality is invoked is when your server
> supports versioned collections, and you are using
> VERSION-CONTROL to create a new version-controlled
> collection from a specified version of an existing version
> history.  Only in this case does a version need to be selected
> for the internal members of that new version-controlled
> collection.

Agreed.  The crux for me is how likely this is to occur.  Is there a common
use case that relies on this (rhetorical)?

> When you use VERSION-CONTROL to create a new (non-collection)
> version-controlled resource, you explicitly specify what
> version you want in the VERSION-CONTROL request.

Agreed.

> And in the version-controlled collection case, if your
> server is sensible,

Wait-up<g> I agree with Alan that this is a useful implementation trick to
avoid this cascading of root versions, but if the act of creating a new
version-controlled collection is very rare, I would rather my versioning
server _didn't_ create 'bogus' empty root versions.

From the client's perspective, is it any better to have no members of the
version-controlled collection (and have to fill them in explicitly), or
have the root versions for each member (and likely have to go and update
them explicitly)?  I accept that for the server it is easier to not create
members.

> and has the root version of a collection
> always be an empty collection, then the server does no
> extra work for the VERSION-CONTROL request, because it
> just creates the version-controlled collection with no
> members at all.  You then use UPDATE or MERGE to
> initialize this collection.
>
>    For a CVS repository for our code, we would
>    update/check out potentially thousands of files
>    in a single request. We don't keep a small
>    number of files per 'workspace' when using CVS.
>    We get the whole lot because when compiling
>    subsystem 'X', it includes header files from
>    subsystems 'A', 'B', .... 'W' all which need
>    to be available.
>
> I assume by get, you mean using the HTTP GET method to
> get the content from the server?  If so, you wouldn't
> be requesting this until you have configured your
> workspace properly, i.e. after you have done the MERGE
> that causes the workspace collection to display the
> versions you want.
>
>    I have not read the spec closely enough, but
>    if its not possible now, is there a way to
>    say 'VERSION-CONTROL using label'? If so, maybe
>    labels could be used to 'get most popular choice'
>    or something??
>
> Since we're talking about configuring workspaces, we
> would need to use functionality provided in the
> server-workspace package, which would be baselines,
> not labels.  And yes, you could use a single
> BASELINE-CONTROL request to initialize the collection
> in one round trip.

I guess that I've always though of clients using this mechanism to update a
workspace en-masse.

> Note that if your server does support labels, you can
> use UPDATE with a Depth and Label header to configure
> the workspace.  Since the initial VERSION-CONTROL request
> is inexpensive,

'inexpensive' -- if the server does this empty root version trick,
otherwise it would have to create the deep tree of version-controlled
resources, which is unknown cost.

> there would be no reason to bundle the UPDATE functionality
> into the VERSION-CONTROL request (2 round trips is not
> an unreasonable number of requests to configure a workspace).

I agree that bundling the update with the version-control is not right.

>    Or during checkin etc, is it worth having a property
>    on a version saying "I am now the best default choice"
>    - similar to the DMA concept of the latest version in
>    the primary version series.
>
> The "best default choice" is appropriately modeled as a
> workspace (for the server-workspace packages) or a label
> (for the client-workspace packages).

or a baseline if you do those.


The members of a version-controlled collection created from a collection
version are:
(1) the DAV:root-version of the member's history (as proposed)
an implementation note should be added to state that severs may chose to
make root-versions of versioned collections empty to avoid cascading
version-controlled collections.

(2) undefined and have to be explictly created by another
version-control/merge request.
i.e. when the version-controlled collection is created a PROPFIND depth 1
would answer the internal member names, but attempts to GET them would
return 404 Not Found.

(3) the spec is silent and servers do what they choose.
It seems that clients are very likely going to have to go and fix-up all
the members anyway so who cares about the initial value.

(4) forget that I even mentioned "latest" :-(
Geoff wrote:
> "latest" is a very bad choice ... I believe that selecting
> the DAV:root-version is significantly superior.
I agree that leaping around across branches is less than optimal, I was
stumbing towards Alan's notion of the "linear series"


Regards,
Tim

Received on Thursday, 5 July 2001 05:37:05 UTC