RE: checked-out VCC (was: Re: Versioning TeleConf Agenda, 4/6/01 (Friday) 12-1pm EST)

   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   Geoff wrote:
   > In versioning, a good way of determining what the "state"
   > of a version-controlled resource consists of, is to create
   > a version of it, and see what is stored in that version.

   'suppose that depends on your definition of 'good'.  Since we are talking
   about configurations it could be a good way of using up lots of server
   cycles and disk space.

When I said "a good way of determining", I meant from a logical
perspective, i.e. what would be a consistent way of interpreting
the protocol.

   In general it should be possible to just query the state of the
   version-controlled resource directly without having to make a version of
   it.  (I could take a photo of you to see what you look like, but if you
are
   there for the photo...)

The point here is that you logically have two objects located at the
same URL; namely, a collection and a configuration.  The
version-controlled collection contains the "depth:0" (or "shallow")
state at that URL, while the version-controlled configuration contains
the "depth:infinity" (or "deep") state of the configuration rooted at
that same URL.

So "the state" of the version-controlled configuration is the
depth:infinity state of its associated baseline-controlled collection.

   > If you create a version (i.e. baseline) of a version-controlled
   > configuration, you see a snapshot of the state of all
   > members of the configuration rooted at the baseline-controlled
   > collection.

   This is true.

At least we agree on that (:-).

   > I believe this is a compelling argument for the
   > statement that the state of the version-controlled configuration
   > is the state of the configuration rooted at the baseline-
   > controlled collection (also, that's what the protocol says :-).

   I agree with the conclusion, but don't see that as a compelling argument.

Well, I guess it doesn't matter what road you take, as long as we
get to the same destination (:-).

   The version-controlled configuration represents the deep hierarchy of
   version-controlled resources rooted at the baseline-controlled
collection,
   and is only necessary to distinguish operations on the configuration from
   those on the (shallow) root collection.  Had we chosen some other
mechanism
   then there would be no need for the version-controlled configuration.

I agree.

   Just as a version-controlled resource can differ from the checked-out
   version to which it refers, there is every reason to believe that the
   version-controlled configuration can differ from the baseline.

I agree.

   This
   implies (to me) that it may be in the checked-out state for extended
   periods of time.  In fact, it would be unusual for it to be checked-in
   other than during the baseline snapshot.

And if you explicitly use the DAV:keep-checked-out parameter to CHECKIN,
it never is in the checked-in state.  But I agree that the "implicit
presence
of DAV:keep-checked-out" is rather anomalous.

   > Note that Greg and Edgar are making a different argument:
   > they agree that the state of the version-controlled configuration
   > is the state of the configuration rooted at the baseline-
   > controlled collection,

   We all agree.

OK, then all of us reached that common destination, so that's a good thing!

   > but they argue that protocol should
   > be changed to say that the baseline-controlled collection
   > should not be modifiable while version-controlled configuration
   > is checked in (the protocol currently makes no such requirement).
   > I'll respond to that in a separate message.

   I understand their position, but if we believe that the
version-controlled
   configuration resource is a 'proxy' for operations on the configuration
   (rather than _being_ the resources in the configuration), it is
   unneccessary for it to be a version-controlled resource at all.  Maybe it
   should not be checked-out or checked-in, but subject to some other method
   that means 'take a baseline shapshot'.  Could be BASELINE, or whatever.

Yes, that's another approach (and one that we even used in a few drafts
quite a while ago).  The problem was that we had to explain how this
non-version-controlled resource was creating something that had all the
properties of a version history (where each version in the version 
history was a baseline).   We did so, but it required duplicating
most of the versioning semantics text, just replacing "version" with
baseline everywhere.

Perhaps the easiest thing to do is to add an "always-checkout" value
to the DAV:auto-version property, where this checks out the version-
controlled resource on any update, but leaves it checked out until
an explicit "CHECKIN" is invoked.  A server that wants to interoperate
with a CHECKIN-aware but baseline-unaware client, could then just set
"always-checkout" on the version-controlled configuration.
Does this sound better than the "VCC is always checked out" approach?
It does address the issue with minimal impact on the protocol.

Cheers,
Geoff

Received on Thursday, 12 April 2001 08:50:52 UTC