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).
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.
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 is possible to recognise which type of client we are talking to, at all
relevant times.
+ A non-Subversion DAV client never needs or wants to see a Subversion "comment".
+ A Subversion client never needs to see a DAV "comment". (The only reason it
might want to is to display it for diagnostic puposes, in the hope that a human
might recognise something in it. I'm assuming that either we can live without
this, or we can always send the "comment" to Subversion clients and they can
decide whether to display it, if they know by some means whether it is a
Subversion or a DAV 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.
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.
Does this make sense?
- Julian
>
> Proposed Solution:
>
> A. Add a new boolean field to the svn_lock_t structure. It would be
> named "xml-packaged-comment", or something similar. It defaults to
> 0, and if set, it means that lock->comment is packaged in XML.
>
> B. When writing locks to the repository:
>
> 1. svnserve (and other non-dav writers) continue normally,
> creating repository locks with the new boolean==0. They
> effectively ignore the new field.
>
> 2. mod_dav_svn notices whether the incoming lock was created by
> an svn client or a generic DAV client. (There are many ways
> to do this, and they've already been discussed elsewhere.)
> If the lock comes from an svn client, the XML-packaging is
> stripped and the lock is written with the boolean==0. if the
> lock comes from a generic DAV client, the packaging is
> preserved and the lock is written with the boolean==1.
>
> C. When reading locks from the repository:
>
> 1. svnserve (and other non-dav readers) continue to read locks
> normally, ignoring the new boolean field. If extra XML junk
> ends up being marshalled back to the client, that simply
> means the lock was created by a generic DAV client. No big
> deal.
>
> 2. mod_dav_svn notices the boolean field when reading. If 0, it
> re-adds the necessary XML wrapper. If 1, it sends the data as-is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 00:39:10 2005