- From: Greg Stein <gstein@lyra.org>
- Date: Thu, 18 Jan 2001 13:04:20 -0800
- To: ietf-dav-versioning@w3.org
On Tue, Jan 16, 2001 at 12:49:01PM -0500, Geoffrey M. Clemm wrote: > > From: Greg Stein <gstein@lyra.org> >... > Specifically, the problem that I'm considering is how to label a baseline > before checking it in. I think that I'm also okay with labelling via a > second request (after the checkin/merge), but that does lead to a race > between the checkin and label that I'd like to avoid if possible. > > With the current protocol, you would have to do the labeling in a > second request (after the version was created). What is the race > condition you were concerned about? The race between the creation of the baseline and the application of the label. Hmm... but that probably doesn't matter that much. The baseline just isn't accessible by a label for that period. > And how would it be addressed > by allowing a label on a working baseline? You could have the label for the baseline available at the moment the baseline is created. Hmm... but this wouldn't even solve the basic problem that I'm after: SVN will automatically label a baseline for later access. The question is how can the SVN client compensate for servers that *don't* auto-label baselines in some way? I have figured out, though, how to discover the auto-labels -- I'll just ask for the DAV:label-name-set in the MERGE operation. It will be non-empty for the new baseline resource, and empty for all the new version resources. [ it would be nice to return nothing at all (e.g. no <DAV:label-name-set/> empty element) for the version resources, but that seems illegal ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Thursday, 18 January 2001 16:03:20 UTC