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

Re: Bug in svnrdump (trunk@1085375) -- malformed dump file with multiple properties

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Fri, 25 Mar 2011 10:31:05 -0500

On Fri, Mar 25, 2011 at 9:50 AM, <neil.winton_at_bt.com> wrote:
> Hi,
>
>
>
> There appears to be a problem with the new svnrdump command handling
> revisions where multiple simultaneous property changes occur on a single
> file or directory. I couldn’t see any mention of this in the user or dev
> lists elsewhere.
>
>
>
> To recreate to bug, do the following:
>
>
>
> svnadmin create test-original
>
> svnadmin load test-original < original.dump
>
> svnrdump dump file://$PWD/test-original > new.dump
>
> svnadmin create test-new
>
> ln -s /bin/true test-new/hooks/pre-revprop-change
>
> svnrdump load file://$PWD/test-new < new.dump
>
>
>
> The result of the load (also using svnadmin instead of svnrdump) is:
>
>
>
> * Loaded revision 0.
>
> svnrdump: E140001: Unrecognised record type in stream
>
>
>
> The problem appears to be that multiple property changes are not
> consolidated into a single set of changes associated with a node, but
> instead appear as “orphaned” Prop-delta sections. So in the original dump
> you see:
>
>
>
> Node-path:
>
> Node-kind: dir
>
> Node-action: change
>
> Prop-content-length: 42
>
> Content-length: 42
>
>
>
> K 3
>
> foo
>
> V 3
>
> bar
>
> K 3
>
> bar
>
> V 3
>
> baz
>
> PROPS-END
>
>
>
> But in the output from svnrdump this appears as follows:
>
>
>
> Node-path:
>
> Node-kind: dir
>
> Node-action: change
>
> Prop-delta: true
>
> Prop-content-length: 26
>
> Content-length: 26
>
>
>
> K 3
>
> foo
>
> V 3
>
> bar
>
> PROPS-END
>
>
>
>
>
> Prop-delta: true
>
> Prop-content-length: 26
>
> Content-length: 26
>
>
>
> K 3
>
> bar
>
> V 3
>
> baz
>
> PROPS-END
>
>
>
> Sorry, but I’m not quite up to providing a fix as yet, but I hope this helps
> someone to figure it out.

Neil,
Thanks for the report. In attempting to reproduce, I wasn't even able
to get as far as comparing the dumpfiles, as svnrdump asserted
somewhere in the process. I opened issue 3844[1] to track this bug,
and committed an XFailing test in r1085428. I also marked the issue
as important for a 1.7.0 release.

-Hyrum

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3844
Received on 2011-03-25 16:31:39 CET

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.