Simplicity of core versioning support

A couple comments were on how simple a "core versioning" server might be...

> >   Section 2.3, Labeling a version
> >   Labeling a version should not be a required feature of "core"
> > support for
> >   versioning.  Core versioning can get away with only having
> >server-defined
> >   version names.  This simplifies support for the Target header and
other
> >   functionality.
>
> How does only having server-defined version names simplify
> support for the Target header?  Do you really not want to
> give the client any way to define a human meaningful name
> for a version?  That seems rather harsh.

If a server is allowed to have only server-defined version names, this
simplifies support for a number of things.
 - don't have to support the new LABEL method (new body semantics, etc.)
 - don't have to support the "label-name-set" property with its special
multi-value semantics
 - don't have to worry about duplication/uniqueness of labels
 - SET-TARGET becomes simpler because it can only refer to a unique
version-name

I agree that in some user scenarios (e.g. source control) it would be harsh
to not allow human-meaningful labels, but in other user scenarios I believe
people won't miss the functionality.

Here's the most basic versioning scenario for non-source-control.  A bunch
of Word docs, HTML docs, stuff like that, are in a multi-user directory.
All the owner wants to do is keep around version history in case somebody
screws up inadvertently and deletes stuff which should stay in there.  If
that happens, all they have to do is go back to a previous version -- maybe
one or two revisions back -- and find the deleted stuff.  In this scenario,
does anybody need or miss the labeling functionality?  Probably 99% of the
time they won't even use SET-TARGET -- the latest version is what everybody
will use and refer to.

Really, this use of versioning can be modeled as part of archiving.  In
archiving do people label stuff with human-readable descriptions of the
state of the file?  No, they typically have a tape with a date on it, and
each file archived to tape has its standard file name.  (Versioning plus
tape-style archiving is better than archiving alone, because every
intermediate version is saved, not just periodic snapshots )

:)  Hey, if you replace LABEL and SET-TARGET with PROPPATCH, even with
PROPPATCH extended to support multi-value-add, I won't argue about the label
functionality any more!

>    Section 5.2.2/3/4, DAV:predecessor-set, DAV: successor-set,
>    DAV:checkout-set
>    Please clarify that for "core" versioning support, since in
> "core" there is
>    no way to fork or merge, that the "predecessor-set" and "successor-set"
>    will
>    only contain one element.  Right?
>
> In core versioning, there is no way to merge, but you can fork
> (just checkout and checkin a version that already has a successor).

Again, I'd like to argue that in non-source-control situations, versioning
doesn't need to support forking.  If I checkout and checkin version 6, when
version 7 already exists, then version 8 is created.  Or, why can't the
server prevent >1 checkout -- it may only have one place for a working
resource?  Then forks would be impossible.

My reasoning is simply that it's an unnecessary burden.  Outside of
source-control domains, I don't think users/clients have, or if they have
they don't usually need, the level of sophistication required to deal with
forks.  What happens when I take "consultant-contract.doc" and I
conceptually want to "fork" it so that I can have one descendant tailored
for programmers and one for editors?  I copy "consultant-contract.doc" to
"editor-contract.doc", creating two independent versioned resources that
happened to start from the same content.  Now it's easier for other users to
find the contract they need, because they have independent names, and each
one has its own single-line-of-descent versioning tree.  I believe this is
how "forking" actually works outside of source-control situations.

For both labels and forking, why not just make these features part of
advanced versioning?  Then servers can choose to implement those features.
I'm assuming here that "core" means "all these features MUST be implemented
for a server to be standard-compliant", and that's why I'm concerned to
keeping the list simple.

lisa

Received on Thursday, 5 October 2000 12:15:45 UTC