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

>    How do you feel about making the new version-controlled resources
>    have a DAV:checked-in of the (chronologically) latest version
>    instead?  I have no great desire for this, but just think it may be
>    more client friendly.
> 
> In the presence of forking, "latest" is a very bad choice, because it
> would cause the initial state to unpredictably jump from one line of
> descent to another.  So I believe that selecting the DAV:root-version
> is significantly superior.

DMA "solved" this problem by using a slightly different versioning
construct to DeltaV (I am not suggesting DeltaV change - I bring it
up for comparison only). In DMA, a "Config History" is the equivalent
to "version history". Each Config History has multiple "Version Series".
Each Version Series is a linear list of versions. Branching is supported
by having a primary Version Series then other Version Series split off
from existing version series (branch) and possibly terminate into existing
version series (merge).

So in DMA, you could make the default the 'most recent version in the
primary version series'.

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. 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 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??
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.

Alan

Received on Wednesday, 4 July 2001 22:11:21 UTC