Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

No need to drive it further at this time.

Thank you.

Doug

On Thu, Feb 23, 2017 at 9:15 AM, Julian Foad  wrote:

> Doug Robinson wrote:
>
>> https://issues.apache.org/jira/browse/SVN-4672
>>
>
> Thanks, Doug, that's great. Let me know if you need me to drive it
> further; I'm assuming not.
>
> Bert wrote:
>
>> That code is in the backing code for svn_ra_replay(), where it also
>> applies to authz, not on the client.
>>
>
> That makes sense. I believe both svnrdump and svnsync use this. I assumed
> both of them would support converting copies to adds...
>
> @Julian Foad Can we use svnsync in this scenario, or does that break in a
>> similar way?
>>
>
> ... but I haven't tested it.
>
> - Julian
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Bug in "svnrdump" ?

[Julian Foad]

Doug Robinson wrote:

https://issues.apache.org/jira/browse/SVN-4672


Thanks, Doug, that's great. Let me know if you need me to drive it 
further; I'm assuming not.


Bert wrote:

That code is in the backing code for svn_ra_replay(), where it also applies to 
authz, not on the client.


That makes sense. I believe both svnrdump and svnsync use this. I 
assumed both of them would support converting copies to adds...



@Julian Foad Can we use svnsync in this scenario, or does that break in a 
similar way?


... but I haven't tested it.

- Julian

RE: Bug in "svnrdump" ?

[bert]

That code is in the backing code for svn_ra_replay(), where it also applies to 
authz, not on the client.

@Julian Foad Can we use svnsync in this scenario, or does that break in a 
similar way?

 Bert

Sent from Mail for Windows 10

From: Julian Foad
Sent: woensdag 22 februari 2017 15:11
To: Doug Robinson
Cc: dev
Subject: Re: Bug in "svnrdump" ?

Doug Robinson wrote:
> This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of
> the simple test case repo.

Thanks. I was hasty -- I see what's going on. This is dumping a subtree 
of the repo (/B/Trunk), and r2 was not dumped because it doesn't touch 
the subtree, and it fails on r3 corresponding to step 3. This feature 
(dump a subtree) is not possible with 'svnadmin dump'.

So the bug is that svnrdump doesn't know how to handle a copy source 
that's outside the subtree being dumped.

That's rather poor. I believe the desired behaviour would be to replace 
the 'copy' with a full 'add', and I believe that behaviour is 
implemented somewhere else -- is it in svndumpfilter and/or svnsync?

If you could file a bug report that would be very helpful, thanks.

- Julian


> If so then it has a reproducible bug:
> --
> 1. Add following files into an empty repo.
>
>A /A
>
>A /A/AA
>
>A /A/AA/a.txt
>
>A /A/AA/b.txt
>
> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>
>A /B (from /A:1)
>
>D /B/AA/a.txt
>
> 3. Copy folder B/AA to folder B/Trunk/AA
>
>A /B/Trunk
>
>A /B/Trunk/AA (from /B/AA:2)
>
> 4. run svnrdump command to dump B/Trunk folder.
>
> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>
> * Dumped revision 0.
>
> * Dumped revision 1.
>
> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
> --
>
> Is this known already?  Should I file a bug?

Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

https://issues.apache.org/jira/browse/SVN-4672

Cheers!

Doug

On Wed, Feb 22, 2017 at 9:11 AM, Julian Foad  wrote:

> Doug Robinson wrote:
>
>> This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of
>> the simple test case repo.
>>
>
> Thanks. I was hasty -- I see what's going on. This is dumping a subtree of
> the repo (/B/Trunk), and r2 was not dumped because it doesn't touch the
> subtree, and it fails on r3 corresponding to step 3. This feature (dump a
> subtree) is not possible with 'svnadmin dump'.
>
> So the bug is that svnrdump doesn't know how to handle a copy source
> that's outside the subtree being dumped.
>
> That's rather poor. I believe the desired behaviour would be to replace
> the 'copy' with a full 'add', and I believe that behaviour is implemented
> somewhere else -- is it in svndumpfilter and/or svnsync?
>
> If you could file a bug report that would be very helpful, thanks.
>
>
> - Julian
>
>
> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Bug in "svnrdump" ?

[Julian Foad]

Doug Robinson wrote:

This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of
the simple test case repo.


Thanks. I was hasty -- I see what's going on. This is dumping a subtree 
of the repo (/B/Trunk), and r2 was not dumped because it doesn't touch 
the subtree, and it fails on r3 corresponding to step 3. This feature 
(dump a subtree) is not possible with 'svnadmin dump'.


So the bug is that svnrdump doesn't know how to handle a copy source 
that's outside the subtree being dumped.


That's rather poor. I believe the desired behaviour would be to replace 
the 'copy' with a full 'add', and I believe that behaviour is 
implemented somewhere else -- is it in svndumpfilter and/or svnsync?


If you could file a bug report that would be very helpful, thanks.

- Julian



If so then it has a reproducible bug:
--
1. Add following files into an empty repo.

   A /A

   A /A/AA

   A /A/AA/a.txt

   A /A/AA/b.txt

2. Svn copy folder A to folder B, and then delete /B/AA/a.txt

   A /B (from /A:1)

   D /B/AA/a.txt

3. Copy folder B/AA to folder B/Trunk/AA

   A /B/Trunk

   A /B/Trunk/AA (from /B/AA:2)

4. run svnrdump command to dump B/Trunk folder.

# svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump

* Dumped revision 0.

* Dumped revision 1.

svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
--

Is this known already?  Should I file a bug?

Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of the
simple test case repo.

Thank you.

Doug

On Wed, Feb 22, 2017 at 8:50 AM, Julian Foad  wrote:

> Doug Robinson wrote:
>
>> Should "svnrdump" be able to dump everything that "svnadmin dump" is
>> capable of?
>>
>
> I'm pretty sure it should, and this isn't a known bug AFAIK (I just
> searched for "svnrdump copy" in Jira).
>
> Thanks for reporting it here.
>
> Can you paste the actual reproduction commands used please. (It isn't
> clear from your description where the commits are, for example. If one
> commit per numbered step, then presumably as it fails on dumping r2 then
> what are steps 3 and 4 for?)
>
> What svn version this is?
>
> - Julian
>
>
>
>> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>> Thank you.
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.


test.dump
Description: Binary data

Re: Bug in "svnrdump" ?

[Julian Foad]

Doug Robinson wrote:

Should "svnrdump" be able to dump everything that "svnadmin dump" is
capable of?


I'm pretty sure it should, and this isn't a known bug AFAIK (I just 
searched for "svnrdump copy" in Jira).


Thanks for reporting it here.

Can you paste the actual reproduction commands used please. (It isn't 
clear from your description where the commits are, for example. If one 
commit per numbered step, then presumably as it fails on dumping r2 then 
what are steps 3 and 4 for?)


What svn version this is?

- Julian




If so then it has a reproducible bug:
--
1. Add following files into an empty repo.

   A /A

   A /A/AA

   A /A/AA/a.txt

   A /A/AA/b.txt

2. Svn copy folder A to folder B, and then delete /B/AA/a.txt

   A /B (from /A:1)

   D /B/AA/a.txt

3. Copy folder B/AA to folder B/Trunk/AA

   A /B/Trunk

   A /B/Trunk/AA (from /B/AA:2)

4. run svnrdump command to dump B/Trunk folder.

# svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump

* Dumped revision 0.

* Dumped revision 1.

svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
--

Is this known already?  Should I file a bug?

Thank you.

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

[neil.winton]

 I committed a patch which fixes issue #3847 in r1092783.  Neil, if you
 want to get this revision to validate the fix in your environment, I'd
 be much obliged.

I've tested this out locally with dumps/restores from a number of our 
repositories and it all looks good.

Thanks guys!

Neil

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

[Hyrum K Wright]

On Tue, Mar 29, 2011 at 4:06 PM, C. Michael Pilato cmpil...@collab.net wrote:
 On 03/28/2011 08:26 AM, neil.win...@bt.com wrote:
 Sorry, but no cigar :( This probably fixes the assertion found by Hyrum,
 but doesn't address the original issue.

 To simplify things, I've repurposed issue #3844[1] to track the problem
 that Hyrum was solving, and opened a new issue #3847[2] for this issue.

 -- C-Mike

 [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3844
 [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3847

I committed a patch which fixes issue #3847 in r1092783.  Neil, if you
want to get this revision to validate the fix in your environment, I'd
be much obliged.

Best,
-Hyrum

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

[Daniel Shahaf]

I've taken a shot at a regression test in r1086497.


However, I think we may have a larger problem here:

The svn_delta_editor_t API allows change_dir_prop() calls to be
transmitted only after all directory-children of a directory have been
transmitted [1].  How can we generate a dumpfile given that input?


On the one hand, we don't want to buffer entire subtrees rooted in D
while we're waiting for D's properties.

On the other hand, can we dump the properties of D only after dumping
the entire subtree rooted in D?


I expect the 'svnadmin load parser to want to see an entry for D before
seeing an entry for any of its children.  Which, yes, leaves the option
to dump first a skeleton entry for D, then dump D's subtree, and finally
dump *another* Node-path: D entry --- but that smells ugly, if not in
outright violation of the dumpfile format.


Thoughts?

Daniel


[1] 
 * 4. A producer must call @c change_dir_prop on a directory either
 *before opening any of the directory's subdirs or after closing
 *them, but not in the middle.

neil.win...@bt.com wrote on Mon, Mar 28, 2011 at 13:26:46 +0100:
 On 25 March 2011 at 19:19, Hyrum K Wright wrote
  On Fri, Mar 25, 2011 at 2:11 PM, C. Michael Pilato cmpil...@collab.net 
  wrote:
  On 03/25/2011 11:31 AM, Hyrum K Wright wrote:
  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
 
  See r1085523.
  
  Thanks, Mike.
  
  Neil, when you get a chance, could you test a r1085523 and see if it
  fixes your problem?
  
  Cheers,
  -Hyrum
 
 Hi guys,
 
 Sorry, but no cigar :( This probably fixes the assertion found by Hyrum, but 
 doesn't address the original issue. The current test case added to the test 
 suite addresses loading multiple propedits. That's good, but it's not 
 sufficient. The heart of the issue is that a transaction with multiple 
 propedits to a single path is *dumped* incorrectly. So for an original dump 
 representation like this:
 
 ---
 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
 ---
 
 The svnrdump output for the same transaction comes out like this:
 
 ---
 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
 ---
 
 Note the second orphaned prop-delta.
 
 It would be great if svnrdump produced exactly the same output as svnadmin 
 (it'd make the test assertions nice and easy), but from a bit of 
 experimentation (I haven't read the svnadmin code here) I don't believe that 
 it's necessary for the two prop-deltas actually to be merged for the dumpfile 
 to be valid. So if it's easier to repeat the preceding node-path information 
 for each prop-delta then I guess that would be OK, as long as the net result 
 is the same.
 
 Thanks,
 Neil

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

[C. Michael Pilato]

On 03/28/2011 08:26 AM, neil.win...@bt.com wrote:
 Sorry, but no cigar :( This probably fixes the assertion found by Hyrum,
 but doesn't address the original issue.

To simplify things, I've repurposed issue #3844[1] to track the problem
that Hyrum was solving, and opened a new issue #3847[2] for this issue.

-- C-Mike

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3844
[2] http://subversion.tigris.org/issues/show_bug.cgi?id=3847

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

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

[neil.winton]

On 25 March 2011 at 19:19, Hyrum K Wright wrote
 On Fri, Mar 25, 2011 at 2:11 PM, C. Michael Pilato cmpil...@collab.net 
 wrote:
 On 03/25/2011 11:31 AM, Hyrum K Wright wrote:
 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

 See r1085523.
 
 Thanks, Mike.
 
 Neil, when you get a chance, could you test a r1085523 and see if it
 fixes your problem?
 
 Cheers,
 -Hyrum

Hi guys,

Sorry, but no cigar :( This probably fixes the assertion found by Hyrum, but 
doesn't address the original issue. The current test case added to the test 
suite addresses loading multiple propedits. That's good, but it's not 
sufficient. The heart of the issue is that a transaction with multiple 
propedits to a single path is *dumped* incorrectly. So for an original dump 
representation like this:

---
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
---

The svnrdump output for the same transaction comes out like this:

---
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
---

Note the second orphaned prop-delta.

It would be great if svnrdump produced exactly the same output as svnadmin 
(it'd make the test assertions nice and easy), but from a bit of 
experimentation (I haven't read the svnadmin code here) I don't believe that 
it's necessary for the two prop-deltas actually to be merged for the dumpfile 
to be valid. So if it's easier to repeat the preceding node-path information 
for each prop-delta then I guess that would be OK, as long as the net result is 
the same.

Thanks,
Neil

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

[Hyrum K Wright]

On Fri, Mar 25, 2011 at 9:50 AM,  neil.win...@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

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

[C. Michael Pilato]

On 03/25/2011 11:31 AM, Hyrum K Wright wrote:
 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

See r1085523.

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

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

[Hyrum K Wright]

On Fri, Mar 25, 2011 at 2:11 PM, C. Michael Pilato cmpil...@collab.net wrote:
 On 03/25/2011 11:31 AM, Hyrum K Wright wrote:
 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

 See r1085523.

Thanks, Mike.

Neil, when you get a chance, could you test a r1085523 and see if it
fixes your problem?

Cheers,
-Hyrum