Re: CHECKOUT of a baseline

On Thu, Jan 04, 2001 at 03:19:43PM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
> 
>    Just verifying an assumption...
> 
>    A baseline is a version resource, which would suggest that I can do a
>    CHECKOUT on that resource, modify it, then check it back in.
> 
> Well, you could, but it wouldn't do you much good because because you
> wouldn't be able to modify the DAV:version-set (it does not appear
> on a working resource).

Why not? :-) Below, you state that the protected status is based on what
resource the property appears on. Why couldn't we say the version-set
property appears on a baseline's working resource as an unprotected
property?

> So you have to CHECKOUT a baseline selector, modify it, and then check
> that back in (the baseline selector uses its baseline-controlled
> collection to determine what the DAV:version-set will be).

Hrm. In other words, it only follows the server workspace model; client
workspace people are out of luck :-)

One model says "construct the baseline from what you see in the workspace"
and the other says "construct the workspace from what you see in the
baseline". Subversion uses the latter.

I'd maintain both are valid :-)

>    In my particular case, the CHECKOUT will be part of an activity, the
>    baseline will *not* be auto-versioned, the checkin will occur as part of
>    merging an activity, and the modifications that I'm considering is simply a
>    PROPPATCH.
> 
> If you want to modify the properties of the baseline, you would need
> to LOCK the baseline selector before doing the MERGE.  The

Subversion doesn't support the LOCK method anywhere. Further, this would
pose problems during a simultaneous update. Failure to unlock the selector
properly (client crash, badly-written clients, etc) would pose
administrative nightmares with clearing the lock periodically (yah, yah, we
could force a small timeout on the bugger, but that just brings about other
problems with determining "how long will the MERGE / PROPPATCH take? [over
this network connection]").

> auto-versioning behavior would keep it checked-out until you released
> the lock, which gives you time to update the properties (it's probably
> a good thing to have the lock anyway, to prevent other clients from
> updating those properties while the baseline selector is checked out).

Given a working resource for a baseline, I wouldn't be worred about other
clients modifying the properties.

>    I'm not sure where in the spec it says that "protected" properties are "not
>    protected" on working resources, but I would presume the DAV:version-set
>    and DAV:subbaseline-set properties would fall in this category.
>    [ I don't need to change them, but others might ]
> 
> A property is protected on a resource iff it is marked as "protected"
> when it is defined for that type of resource.  So a property can be
> "protected" on one kind of resource, but not on another.  I'll add
> some words to the document to emphasize this.

Thanks.

And this corresponds with my point above, about allowing the version-set to
be modified on a baseline working resource.

> Notice that the DAV:subbaseline-set property is not protected on a
> baseline selector (so you can PROPPATCH it).

And I'd suggest this could be done on a working baseline.

> You can't PROPPATCH a
> DAV:version-set property on a baseline selector, because it doesn't
> have one.

For that model of modifying a baseline, I agree with you.

>... [ description of MERGE models, updating DAV:version-set, etc ] ...
>...
> For interoperability, it would be far better to have a single mechanism
> (baseline selectors and baseline-controlled collections) for creating
> baselines.  We were forced into the client-workspace/server-workspace
> dichotomy because of significant implementation concerns, but we wouldn't
> want to extend that dichotomy any farther than we have to.  So if it
> is at all reasonable to use baseline-controlled collections to create
> baselines, that would be much better.  Does this present a problem for
> subversion?

Yup. As I mentioned, the baselines are constructed by the server
automatically. The baseline selector simply exposes what it finds.

And... the baseline is constructed as part of the commit process (read: the
MERGE method rather than the UNLOCK of a baseline selector).

Not to mention total lack of support for LOCK/UNLOCK.

Personally, I see a "wart" in the draft if we can't check out a baseline.
Right at the beginning of S9.2, it says, "Since a baseline is a version
resource, ...". To me, that implies I should be able to CHECKOUT the bugger.
Saying that I /can't/ seems to introduce an artificial disparity.

I do understand that limiting the dichotomy might be nice, but the baselines
are just variants of existing things. I say, treat them like the originals.
Otherwise, you have client-workspace clients using two models: server-based
for the baselines, and client-based for the rest.

>    Specifically, I'm looking for a way to add/modify properties on baseline
>    resources. The auto-baseline feature doesn't provide a way to do that, which
>    means that I need to fall back to checking out the baseline. I think a
>    couple sentences can handle what to do when a baseline is being checked in
>    as part of an activity (merge).
> 
> Can you live with the currently defined LOCK/UNLOCK mechanism for
> delaying baseline creation until after the properties are updated?

Sorry, but no.

Allowing a checkout of a baseline, modifying it, and checking it in seems to
be totally fine with the existing draft. Does it actually say that you
*cannot* do this? Assuming no, then this part seems totally fine.

The problem that I'm looking at is with respect to automatically updating
the DAV:version-set during the MERGE operation. That would require an actual
spec change to describe the operation.

My suggestion is to add a bit of text to the Activity CHECKIN stuff to deal
with baseline working resources. Since MERGE is basically doing an Activity
CHECKIN, it will just pick up that behavior (plus a small bit about merging
into a baseline selector).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 4 January 2001 15:50:25 UTC