Re: Bug in "svnrdump" ?

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 >

Re: Bug in "svnrdump" ?

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

RE: Bug in "svnrdump" ?

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 r

Re: Bug in "svnrdump" ?

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

Re: Bug in "svnrdump" ?

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

Re: Bug in "svnrdump" ?

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"

Re: Bug in "svnrdump" ?

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

Bug in "svnrdump" ?

Folks: Should "svnrdump" be able to dump everything that "svnadmin dump" is capable of? 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

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Wed, Dec 12, 2012 at 5:06 PM, Daniel Shahaf danie...@elego.de wrote: P.S. This thread was an unusually long one, for a patch that adds about a dozen lines of code. Uh, how is that at all unusual for this crowd? =) -- justin

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Tue, Dec 11, 2012 at 5:59 PM, Ben Reser b...@reser.org wrote: I'd say that replacing '\r' with a 'space' is wrong. That would change the meaning of some properties. E.G. svn:ignore, svn:externals which use lines to handle individual records within them. To be more explicit, I think you

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Ben Reser wrote on Wed, Dec 12, 2012 at 13:57:30 -0800: On Tue, Dec 11, 2012 at 5:59 PM, Ben Reser b...@reser.org wrote: I'd say that replacing '\r' with a 'space' is wrong. That would change the meaning of some properties. E.G. svn:ignore, svn:externals which use lines to handle

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

#4263: svnrdump: E125005: Cannot accept non-LF line endings in 'svn:log' property * subversion/tests/cmdline/svnrdump_tests.py (copy_bad_line_endings_load): Test for '\r' line ending bug in svnrdump (issue 4263) ]]]

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

): Test for '\r' line ending bug in svnrdump (issue 4263) ]]]

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Gabriela Gibson wrote on Tue, Dec 11, 2012 at 22:18:54 +: On 11/12/12 00:46, Daniel Shahaf wrote: Need parentheses around the symbol name. Lines should be wrapped at 80 characters and subsequent lines indented. The web page instructions[1] need updating because they doesn't mention

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On 12/11/2012 06:01 PM, Daniel Shahaf wrote: Gabriela Gibson wrote on Tue, Dec 11, 2012 at 22:18:54 +: On 11/12/12 00:46, Daniel Shahaf wrote: Need parentheses around the symbol name. Lines should be wrapped at 80 characters and subsequent lines indented. The web page instructions[1]

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On 11/12/12 00:46, Daniel Shahaf wrote: snip subversion/svnrdump/svnrdump.c:554: (apr_err=125005) subversion/libsvn_repos/load.c:583: (apr_err=125005) subversion/libsvn_repos/load.c:260: (apr_err=125005) subversion/svnrdump/load_editor.c:858: (apr_err=125005)

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On 11/12/12 23:01, Daniel Shahaf wrote: Gabriela Gibson wrote on Tue, Dec 11, 2012 at 22:18:54 +: On 11/12/12 00:46, Daniel Shahaf wrote: I will attempt to do just this. Also your tip with the libtool was much appreciated, thank you very much :) Welcome. Index:

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Tue, Dec 11, 2012 at 4:50 PM, Gabriela Gibson gabriela.gib...@gmail.com wrote: I'm concerned that I shouldn't be altering fs-wrap.c. So a logical place to put a fix is probably in (set_revision_property). I could either hand code a for loop, or call the function

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Ben Reser wrote on Tue, Dec 11, 2012 at 17:44:59 -0800: I tracked that down by looking at the issue that's referenced in the issue you're looking at, which then says it is fixed in r37795. When we migrated from tigris.org to apache.org for our repo hosting our revision numbers changed.

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Gabriela Gibson wrote on Wed, Dec 12, 2012 at 01:16:34 +: The differences between copy-bad-line-endings.expected.dump and copy-bad-line-endings.dump appear to be: 1. '\r' in the middle of a line is replaced by '\n'. 2. '\r' at the end of a line is deleted. Actually what happens in (2)

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Tue, Dec 11, 2012 at 5:16 PM, Gabriela Gibson gabriela.gib...@gmail.com wrote: The differences between copy-bad-line-endings.expected.dump and copy-bad-line-endings.dump appear to be: 1. '\r' in the middle of a line is replaced by '\n'. 2. '\r' at the end of a line is deleted. Let's

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Ben Reser wrote on Tue, Dec 11, 2012 at 17:59:47 -0800: Your \r at the end of a line being deleted is in a log message. I suspect we have some code someplace that removes trailing new lines from svn:log. But I haven't dug too far on that. We have code on the client side that removes \r from

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Wed, Dec 12, 2012 at 04:02:01AM +0200, Daniel Shahaf wrote: Ben Reser wrote on Tue, Dec 11, 2012 at 17:59:47 -0800: Your \r at the end of a line being deleted is in a log message. I suspect we have some code someplace that removes trailing new lines from svn:log. But I haven't dug too

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

Gabriela Gibson wrote on Wed, Dec 12, 2012 at 00:50:41 +: On 11/12/12 00:46, Daniel Shahaf wrote: snip subversion/svnrdump/svnrdump.c:554: (apr_err=125005) subversion/libsvn_repos/load.c:583: (apr_err=125005) subversion/libsvn_repos/load.c:260: (apr_err=125005)

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Tue, Dec 11, 2012 at 6:02 PM, Daniel Shahaf danie...@elego.de wrote: We have code on the client side that removes \r from the log message supplied by the user. (I don't really remember whether that is in 'svn' (the cmdline client) or in libsvn_client.) That would be the

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

On Tue, Dec 11, 2012 at 3:14 PM, C. Michael Pilato cmpil...@collab.net wrote: We should probably link to the Coding Conventions section from the Patch submission guidelines section just to be thorough. Done in r1420516.

[PATCH] Test for line ending bug in svnrdump (issue 4263)

[[[ Test for issue #4263: svnrdump: E125005: Cannot accept non-LF line endings in 'svn:log' property * subversion/tests/cmdline/svnrdump_tests.py copy_bad_line_endings_load: Test for \r line ending bug in svnrdump (issue 4263) ]]] Index: svnrdump_tests.py

Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)

for \r line ending bug in svnrdump (issue 4263) Need parentheses around the symbol name. Lines should be wrapped at 80 characters and subsequent lines indented. ]]] Index: svnrdump_tests.py === --- svnrdump_tests.py (revision

[PATCH] Test for line ending bug in svnrdump (issue 4263)

[[[ Test for issue #4263: svnrdump: E125005: Cannot accept non-LF line endings in 'svn:log' property * subversion/tests/cmdline/svnrdump_tests.py copy_bad_line_endings_load: Test for \r line ending bug in svnrdump (issue 4263) ]]] Index: svnrdump_tests.py

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

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

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]

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

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

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

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

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

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,

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

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

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

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

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

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

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

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