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

"Clemm, Geoff" <gclemm@rational.com> wrote:
> While investigating the new "auto-checkout-manual-checkin" value for
> DAV:auto-version, it appeared to me that things could be made
> significantly clearer if we replace the DAV:auto-version property with
> a DAV:auto-checkout and DAV:auto-checkin property.  This lets us
> specify auto-checkout behavior independently from auto-checkin
> behavior, which is what we need/want for "auto-checkout-manual-checkin".
DAV:auto-checkout and DAV:auto-checkin sound sensible. So if this means
that for a baseline-aware client the version-controlled-configuration
normally is in a checked-in state and to help non baseline-aware
clients the server can use these these properties it's okay with me.


"Clemm, Geoff" <gclemm@rational.com> wrote:
> The point here is that you logically have two objects located at the
> same URL; namely, a collection and a configuration.
Exactly. This unavoidable dualism is the root of our problems.

> 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.
So we decided to take the shallow variant as the collection version
and took 'configuration' and 'baseline' for the deep variant.
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.

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.
But nevertheless thats a feature another SW group and I found missing when
we evaluated Clearcase a while ago. Clearcase Components are shallow constructs
like configurations (I hope it's allowed to mention a tool here to illustrate
my point).
My experience with projects beginning with a couple of thousand files and heavy
reuse of code between different executables tells me that hierachically structured
components (Here called configurations) are a natural way to work.

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.

Cheers and happy Easter, Edgar

-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Sunday, 15 April 2001 06:00:56 UTC