On Feb 17, 2005, at 5:38 PM, Julian Foad wrote:
> Ben Collins-Sussman wrote:
>> We want the new locking feature to be well-designed in its own right,
>> but we also want it to be interoperable with generic DAV clients, so
>> that autoversioning really gets finished.
>
> This is my reading of the situation:
>
> The locking system stores and retrieves a piece of opaque data that it
> calls the "comment". Generic DAV clients need a DAV "owner" field
> stored in this way, and Subversion clients need a human-readable
> comment stored. A Subversion RA-DAV client is an overlap of the two,
> and the comment is in a DAV "owner" field.
>
> Ignoring the XML wrapping for a moment, and tinking about the
> information content, DAV "owner" and Subversion "comment" are not
> compatible with each other (neither type of client can understand the
> other type of comment).
This is really an exaggeration. *Semantically*, they're the same
thing. They're both just 'comments' describing the lock. They're both
meant to be human-readable.
The problem I ran into was the fact that mod_dav is trying to store the
thing in a funny way, with some extra syntax.
> Therefore we need to store meta-data that says either "This is a
> Subversion comment" or "This is a (non-Subversion) DAV owner field",
> and we need to send the comment to the client only when the comment
> type matches the client type.
>
Not at all. Any generic DAV client may examine the lock, and will very
much want to see a human-readable comment created by an svn client.
And similarly, if a generic DAV client creates a lock, 'svn info URL'
will want to display the comment it creates.
It's *possible* that some DAV clients may store structured data in the
comment, but not guaranteed, and not even that commonly. And when that
happens, it's not as though we have some obligation to screen the svn
client's eyes from that. If the svn client sees it, it's no big deal:
"hey, I guess program <foo> made that lock."
>
> My assumptions:
>
> + It is possible to divide the clients into distinct non-overlapping
> types based on the form of their "comment" data. I think there are
> two types: Subversion, and (non-Subversion) DAV.
It's possible, but entirely easy. I've solved the problem by making
the svn client send a special http header in the LOCK request which
says, "hey, I'm an svn client!"
>
> + It is possible to recognise which type of client we are talking to,
> at all relevant times.
Only because of the header above, and only when locking. There's no
easy way to tell in a PROPFIND, though.
>
> + A non-Subversion DAV client never needs or wants to see a Subversion
> "comment".
>
Not true. I have a java DAV client right here that happily displays
the locks created by svn. It's quite pleasant to see all the fields,
especially the comment.
>
> If I'm right, then the new meta-data should mean "This comment is a
> (Subversion comment | non-Subversion DAV owner field)", rather than
> "This comment is [not] valid XML". It should always be set correctly.
> (Is there any problem with getting RA-local etc. to set it?) It
> should possibly be a multi-valued setting rather than a Boolean, so
> that we can add other comment types in future.
>
> Strip the XML from Subversion comments RA-DAV, but leave it intact for
> generic DAV owner fields, like you said.
This is in fact what I've already committed, essentially. The new
boolean is defined as "is the comment wrapped with extra mod_dav XML?"
The only time mod_dav_svn stores the extra XML wrapper (and sets the
boolean) is when it knows the lock creation is coming from a non-svn
client.
>
> On reading, I recommend that all RA methods take note of the "comment
> type" field and don't read the comment at all if it's not the type
> they want.
Nope, the comment is always a good thing. There's a good semantic
match between DAV and SVN locks here. The trick is just to make sure
that mod_dav_svn creates lock-comments that are always usable by other
RA layers, and that it always sends back valid HTTP to all clients.
This burden is now entirely implemented within mod_dav_svn, and no
other library or layer needs to take notice. The problem is cleanly
solved.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 03:48:25 2005