Re: CHECKOUT of a baseline

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

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

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

   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.

Notice that the DAV:subbaseline-set property is not protected on a
baseline selector (so you can PROPPATCH it).  You can't PROPPATCH a
DAV:version-set property on a baseline selector, because it doesn't
have one.

   Now, one issue that I'm wondering about is the updating of the
   DAV:version-set at MERGE time.    This might actually require a spec change.
   Normally, a baseline's version-set is updated when the MERGE changes the
   VCRs' DAV:checked-in property. 

Actually, a baseline's DAV:version-set is never modified.  Rather, it
is created when a baseline is created (by enumerating the
DAV:checked-in versions of the baseline controlled collection).

   However, I think the order of operations during the merge would
   need to be something like:

   1) check in all non-baseline working resources
   2) update the DAV:version-set of the baseline working resource
   3) check in the baseline working resource
   4) merge the versions into the VCRs and the baseline selector

Currently, it is:

MERGE the activity into the (repository) collection:
 1) check in all working resources 
 2) auto-checkout the baseline selector
 3) merge the versions into the VCR's
 4) auto-checkin the baseline selector, which creates a new baseline
    whose whose DAV:version-set identifies the VCR checked-in versions
    of the (repository) collection.

Or if you want to modify the properties of the new baseline:

LOCK the baseline selector of the (repository) collection
MERGE the activity into the (repository) collection:
 1) check in all working resources 
 2) auto-checkout the baseline selector
 3) merge the versions into the VCR's
PROPPATCH the properties of the locked baseline selector
UNLOCK the baseline selector:
 1) auto-checkin the baseline selector, which creates a new baseline
    whose whose DAV:version-set identifies the VCR checked-in versions
    of the (repository) collection.
 2) remove the lock on the baseline selector

   I'm not sure what the right wording / effect would be. I think that it might
   be sufficient to say something similar to DAV:update-version-set in S10.12:
   that each (non-baseline) version checked in by the merge operation is added
   (or replaces) to the DAV:version-set of the baseline working resource.
   Obviously this would be ambiguous if multiple baselines were checked out
   into an activity and merged, but I'm okay with leaving that undefined. Note
   that you can't match up version histories to see which baseline version-set
   to update since newly-added resources would have no corresponding version
   (history) in the checked out baseline.

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?

   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?

Cheers,
Geoff

Received on Thursday, 4 January 2001 15:20:37 UTC