[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

DAV locking question

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2005-01-12 19:28:26 CET

Hey Greg Stein,

I'm wondering if I've found a bug or weirdness in mod_dav's locking
code.

Neon sends a totally rfc-compliant LOCK request with a body like this:

<?xml version="1.0" encoding="utf-8"?>
<lockinfo xmlns='DAV:'>
   <lockscope><exclusive/></lockscope>
   <locktype><write/></locktype>
   <owner>newlock</owner>
</lockinfo>

But then when I peer directly into the svn repository with 'svnadmin
lslocks', I see namespace junk around the field. (By the way, I'm
mapping the 'owner' field to the svn_lock_t's 'comment' field, as
discussed before):

      UUID Token: opaquelocktoken:e7b934b9-7eed-0310-a22f-e4167952b748
           Owner: sussman
         Comment: <ns0:owner xmlns:ns0="DAV:">newlock</ns0:owner>
         Created: 2005-01-12 12:10:59 -0600 (Wed, 12 Jan 2005)
         Expires: never

That's pretty odd. In my dav_svn_append_lock() provider callback, I'm
just literally copying the dav_lock->owner field into
svn_lock_t->comment, assuming that mod_dav would be kindly stripping
away the xml tags for me.

But sure enough, I see this comment in the definition of the dav_lock
struct:

     const char *owner; /* (XML) owner of the lock */

Whassup with that? Is there a reason that the owner field is being
stored with XML stuff around it? That's a bit of RA-specific "bleed"
that we shouldn't be storing in the repository.

Is my provider supposed to strip that XML stuff away? And if so, how?
Am I allowed to make any assumptions about what sort of XML is there
(i.e. is it safe to unconditionally strip away the outermost tag?)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 19:30:56 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.