RE: Re (2): checked-out VCC: A new proposal

   From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

   I still wonder wheter it would be possible to drop the terms
   'configuration' and 'baseline'.  Just let's define a version of a
   collection as the deep variant which you get by a plain vanilla
   VERSION-CONTROL on the collection.  Then you have 'basic' resources
   (no collections) with their versions and collections (meaning the
   whole tree) and their versions.  I would do that because I'm not
   yet persuaded whether we really need the (shallow)
   version-controlled-collection. It's rationale seems to be a little
   bit technically based. It is believed that it is necessary to
   untangle working with activities, merging and workspaces. So it's
   not a feature of it's own value but only for support of other
   features.  I have the feeling that this activity problem could be
   solved in another way.  To try to understand the problem I will
   reread the stuff on activities, merge,
   version-controlled-collection and workspaces (rather entangled :-)
   a couple of times. Perhaps it will help.

Yes, the rationale for supporting both versions and baselines of
collections is based on requirements of activities and merging, but
sometimes hard problems don't have simple answers (:-).  But I'm
always interested in discovering simpler answers to hard problems, so
please do keep investigating.

   Then an important point for me where I didn't get any feedback
   yet. I proposed to define a configuration (to use the current term)
   as the tree beginning at root collection EXCLUDING
   BASELINE-CONTROLLED sub-collections. This would be a very small
   change in the protocol and also be cheap in implementation I guess.

Sorry if I didn't make it clearer earlier, but I agree with the point
you raise here.  It was a key component of another thread a month or
so ago (I can't remember the thread title ... Greg started it, I
believe).  The final resolution was that every member of a
baseline-controlled collection got its own
DAV:version-controlled-configuration property.  This clarified that a
configuration does not contain version-controlled members of a nested
configuration, which I believe is what you are asking for here.  You
use the DAV:subbaseline-set to add nested configuration baselines to a
baseline.

   All in all I can live with the existing terms. Better alternatives
   to cope with the abovementioned dualism aren't easy to find.
   What's important are the features I get and as I see it now they
   are there with the exception of my last point.

Great!  It looks like you actually get all the features you want,
since the latest rev of the spec fixes gives you that last feature
as well.

Cheers,
Geoff

Received on Monday, 16 April 2001 17:55:29 UTC