Re: mod_dav_svn backward compatibility broken?

Branko Čibej <brane@xbc.nu> writes:

> Why can't we jiust marshal the uuid as a property that just happens to
> be present on every versionable resource? That not only makes sense
> semantically (since we should be storing the uuid in the entries file),
> it also means that any DAV client will see it, but can ignore it.

Um, yes, that's exactly what we're doing. If you use WebDAV to ask a
resource for all its properties, you'll see the UUID, DAV props, and
user-controlled props.

The problem is that our "custom" update report returns the
non-user-controlled props within the tree delta -- on each resource.
Here's a bit of the tree-delta sent back during an update:

<S:add-file name="python_3bits.txt"
result-checksum="ec816060540c0da8ea6c882cf470913c" >

<D:checked-in><D:href>/svn/repo4/!svn/ver/1/3bits/python_3bits.txt</D:href>
</D:checked-in>

<S:prop>
<D:version-name>1</D:version-name>
<D:creationdate>2003-03-04T18:40:09.748608Z</D:creationdate>
<D:creator-displayname>sussman</D:creator-displayname>
<S2:repository-uuid>cb4d11d7-0fb8-0310-b2e3-bd6612ce3422
</S2:repository-uuid>
</S:prop>

</S:add-file>

And older ra_dav libraries are choking, because they don't think the
<repostiory-uuid> element is valid element in the custom report
language. Grrrr.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 4 20:54:52 2003