W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

CHECKOUT of a baseline

From: Greg Stein <gstein@lyra.org>
Date: Wed, 3 Jan 2001 21:04:14 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010103210413.A18572@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.

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.

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 ]

So... based on my reading, the above is all quite valid.


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

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.


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

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Thursday, 4 January 2001 00:04:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT