Does the naive tweak help?
Index: subversion/libsvn_ra_neon/fetch.c
===================================================================
--- subversion/libsvn_ra_neon/fetch.c (revision 30139)
+++ subversion/libsvn_ra_neon/fetch.c (working copy)
@@ -1307,6 +1307,7 @@
|| child == ELEM_add_directory
|| child == ELEM_absent_file
|| child == ELEM_add_file
+ || child == ELEM_remove_prop
|| child == ELEM_set_prop
|| child == ELEM_SVN_prop
|| child == ELEM_checked_in)
@@ -1330,6 +1331,7 @@
if (child == ELEM_checked_in
|| child == ELEM_txdelta
|| child == ELEM_set_prop
+ || child == ELEM_remove_prop
|| child == ELEM_SVN_prop)
return child;
else
David Glasser wrote:
> Here's today's episode of "Subversion WebDAV RA tries to be too smart
> for its own good instead of just serializing RA API calls like
> ra_svn"!
>
> Before 1.5, server never sent add-with-history to clients, so it would
> never make sense for a "remove prop" XML element to be inside an "add
> file" element.
>
> And in fact, libsvn_ra_neon/fetch.c(validate_element) tries to
> validate this, throwing a corrupted XML error if (among many other
> things) an ELEM_remove_prop is inside an ELEM_add_file. This breaks
> the update. (Similar issues presumably include remove-prop inside
> add-directory, and delete-entry inside add-directory, but perhaps many
> more combinations as well.)
>
> To reproduce, do something like:
>
> $ svn ps foo bar a
> $ svn ci
> Revision 10.
> $ svn cp a b
> $ svn pd foo b
> $ svn ci
> Revision 11.
> $ svn up -r10
> $ svn up -r11
>
> I have no idea if serf has this bug; I've just verified that ra_svn
> and ra_local don't.
>
> I don't really know enough about Neon to feel comfortable trying to
> fix this, but it's a serious 1.5-blocker of a bug.
>
> --dave
>
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-04-01 19:38:04 CEST