Re: Simplicity of core versioning support

   From: "Lisa Dusseault" <lisa@xythos.com>

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

   If a server is allowed to have only server-defined version names, this
   simplifies support for a number of things.

I've put this suggestion into a separate thread, but a couple of
comments here (to make sure we agree on what "optional labeling" means).

    - don't have to support the new LABEL method (new body semantics, etc.)

Yes, that would become optional.

    - don't have to support the "label-name-set" property with its special
   multi-value semantics

You'd still need the "label-name-set" property (to get
interoperable SET-TARGET and Target-Selector behavior), but it would
just have a copy of the version name in it and wouldn't have any
special multi-value semantics ... it would just be initialized with
the version-name, and not be updateable.

    - don't have to worry about duplication/uniqueness of labels

Yes.

    - SET-TARGET becomes simpler because it can only refer to a unique
   version-name

Just for interest's sake, how does a unique version name simplify
SET-TARGET (I assume by "unique", you mean that each version has
exactly one).  You still need the two options for SET-TARGET: a label
(which in your case would always be a version-name) and a version URL.

   :)  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!

OK, now I'm confused.  What difference does it make to you whether
labeling is marshalled via LABEL or a property update.  You have to
just as much work on your server to support labeling semantics.

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

The purpose of DAV:predecessor is to identify the state of the
resource right before you started changing it.  Storing the current
DAV:latest as the DAV:predecessor would violate these semantics.  You
could certainly support some additional property
(e.g. DAV:previous-latest-at-checkin-time), but that would be a
different property (and not one that appears to be of general enough
interest to standardize upon).

   My reasoning is simply that it's an unnecessary burden.

DAV:predecessor is an extremely simple property to maintain, so
it seems reasonable to require it from all servers.

   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.

A client doesn't have to deal with forks, only a server does.  And
dealing with a fork just means storing the correct value in
DAV:predecessor-set when you create a version, so no sophistication
is required.

   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.

That's fine ... there's nothing in the version control protocol that
prevents you from doing this.  All it asks is that all servers store
a consistent (easily determined) value in DAV:predecessor-set.

   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 sympathetic to your desire to make labeling optional ... that does
require some work (although not really all that much :-).  But the cost
for a server of maintaining an accurate DAV:predecessor-set is so minimal,
that I don't see the argument for making it optional.

   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.

Note that core means "must be implemented by a server", not "must be
exposed by a client".  So the only arguments that are relevant are 
"this would be hard to implement for a server".

Cheers,
Geoff

Received on Thursday, 5 October 2000 15:49:33 UTC