- From: Greg Stein <gstein@lyra.org>
- Date: Mon, 26 Mar 2001 22:44:37 -0800
- To: ietf-dav-versioning@w3.org
On Tue, Mar 27, 2001 at 12:40:51AM -0500, Clemm, Geoff wrote: >... > The consensus of the room at the DeltaV working group session was that > we should remove the Label header, to avoid this internationalization > problems. Since the Label header is an optimization (i.e. you can use > PROPFIND to determine the information), this was considered the > appropriate response to the area directors concern. Note, the proposal > is not to remove the LABEL method, just to remove the Label header. > > Any objections? Hmm. I believe that I do. In my particular scenario, I have a VCC and need to PROPFIND one of many baselines, using a Label as the selector. Without the Label header, I'd have to PROPFIND every single baseline to find the right one, wouldn't I? Is there something that I'm missing? Assuming that I haven't missed something, then yes: I would object. I can't see how to create similar functionality in other ways. >... defer the Variant Option ... > > Any objections? Deferral is fine with me. I have no interest in this, and I honestly don't see it as a useful feature for any versioning server. (IOW, with my personal hat on, and my independent hat on, I see no/little utility) > The third proposed simplification was to defer the "Update Option", > with the intention of leaving it out of the protocol unless its > addition is more strongly motivated than it is currently. In > particular, if you want to expose an older version of a VCR, you can > just check out that VCR, copy that older version into the checked-out > resource, and then check it back in. This has the added advantage > that this does not block future work on a linear versioning server, > the way an UPDATE would (i.e. you can only check out the tip in a > linear versioning server). It also has the advantage that it is more > compatible with the baseline and activity features, that want to > define states as merges of baselines and activities, rather than > manipulations of individual versions. > > Any objections? I'm not sure about the proposed workaround (that appears to alter the tip, rather than expose an older resource), but I see little use for the UPDATE method, too. Consider: if you have a VCR that you intend to point at an old version for a long period of time, then why not just give out the version resource URL to begin with? A server could also use bindings to establish a collection of older items. You could use baselines. Lastly, you could expose a workspace that has been smacked with MERGE to point at old resources. IOW, I tend to see VCRs as always floating to the latest. Tweaking their value (other than as part of a checkin) seems of little utility. I'm happy to defer/punt the feature. >... folding branch control into the core ... > > Any objections? Totally fine. That isn't a big change/imposition. >... packages ... > client workspace configuration management: > core > version-history > working-resource > merge > label > baseline > activity > version-controlled-collection Hey! That looks like Subversion :-) > Any objections to these packages? Nope. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Tuesday, 27 March 2001 01:44:19 UTC