Re: Repository became corrupt on commit
Hi Daniel, > Odd. My first assumption is that the subshell on line 39 isn't behaving > as expected. If you run `svnlook tree --full-paths --show-ids -r 719 > /path/to/repository /trunk/scripts/script.py`, does print a path and a > node-rev id string (which looks like "a.b.c/d-e")? Here is the output that I got: svnlook tree --full-paths --show-ids -r 719 /path/to/repository /trunk/scripts/script.py svnlook: E160016: Failure opening '/trunk/scripts/script.py' svnlook: E160016: '/trunk' is not a directory in filesystem '6b6eeb5b-1909-4e6c-8b33-d77c8e70ace5' If I run this on 718 then I get this output: svnlook tree --full-paths --show-ids -r 718 /path/to/repository /trunk/scripts/script.py /trunk/scripts/script.py <3.0.r716/391789> > These all look correct. I assume that when you do a normal 'verify' > run, revisions 1:718 (inclusive) are verified successfully and 719 > errors out, correct? I.e., it prints "Verifying revision 718" and then > "Error verifying revision 719". That is correct: * Verified revision 718. * Error verifying revision 719. svnadmin: E160013: Filesystem path 'trunk/doc/EDITS.txt' is neither a file nor a directory > There's a slim chance that those "type:" lines had a NUL byte tacked on, > or something else that got lost in the translation to email. You can > rule out this remote possibility by piping the grep to xxd(1) (just > '| xxd', no option flags needed). Here is 718: grep -a '^type:' /path/to/repository/db/revs/718 | xxd : 7479 7065 3a20 6669 6c65 0a74 7970 653a type: file.type: 0010: 2064 6972 0a74 7970 653a 2064 6972 0a74 dir.type: dir.t 0020: 7970 653a 2064 6972 0a74 7970 653a 2064 ype: dir.type: d 0030: 6972 0a74 7970 653a 2064 6972 0a ir.type: dir. And 719: grep -a '^type:' /path/to/repository/db/revs/719 | xxd : 7479 7065 3a20 6669 6c65 0a74 7970 653a type: file.type: 0010: 2064 6972 0a > Otherwise, could you please confirm that the error you're getting on > r719 is the same one you posted for r728 (except for the revision > number, of course)? Yes, although I just noticed that it is a different file in this case but same error code: * Verified revision 718. * Error verifying revision 719. svnadmin: E160013: Filesystem path 'trunk/doc/EDITS.txt' is neither a file nor a directory I re-ran the svnlook commands on this file and get the same results: svnlook tree --full-paths --show-ids -r 719 /path/to/repository /trunk/doc/EDITS.txt svnlook: E160016: Failure opening '/trunk/doc/EDITS.txt' svnlook: E160016: '/trunk' is not a directory in filesystem '6b6eeb5b-1909-4e6c-8b33-d77c8e70ace5' And on 718: svnlook tree --full-paths --show-ids -r 718 /path/to/repository /trunk/doc/EDITS.txt /trunk/doc/EDITS.txt <166.0.r717/510746> Regards, Alan On Wed, Oct 24, 2018 at 3:08 PM Daniel Shahaf wrote: > > Alan Spark wrote on Wed, 24 Oct 2018 08:57 +0100: > > Hi Daniel, > > > > I didn't get anywhere with the perl script. /usr/bin is definitely in > > the path and that is where svnlook is, and the SVNLOOK variable was > > already set... anyway I gave up and went for your alternative. > > > > Odd. My first assumption is that the subshell on line 39 isn't behaving > as expected. If you run `svnlook tree --full-paths --show-ids -r 719 > /path/to/repository /trunk/scripts/script.py`, does print a path and a > node-rev id string (which looks like "a.b.c/d-e")? > > > Firstly I must apologise as I stated revision 728 in my original email > > but it looks like this was on one of our experimental copies of the > > repository that we no longer have. I do still have a copy of the > > broken repository at revision 719. With that in mind, I ran this: > > > > grep -a '^type:' /path/to/repository/db/revs/719 > > type: file > > type: dir > > > > I also ran on the last working revision: > > > > grep -a '^type:' /path/to/repository/db/revs/718 > > type: file > > type: dir > > type: dir > > type: dir > > type: dir > > type: dir > > > > These all look correct. I assume that when you do a normal 'verify' > run, revisions 1:718 (inclusive) are verified successfully and 719 > errors out, correct? I.e., it prints "Verifying revision 718" and then > "Error verifying revision 719". > > There's a slim chance that those "type:" lines had a NUL byte tacked on, > or something else that got lost in the translation to email. You can > rule out this remote possibility by piping the grep to xxd(1) (just > '| xxd', no option flags needed). > > Otherwise, could you please confirm that the error you're getting on > r719 is the same one you posted for r728 (except for the revision > number, of course)? > > > I note that your path had a /0/ after /revs/ but this appears to be empty. > > > > It's normal for that path not to exist, particularly in older repositories. > It > shouldn't exist empty, but that's harmless. > > > I think I have confirmed that our MPM is prefork: > > > > a2query -M > > prefork > > > > I hope this helps. Let me know if you need me t
Coredump when javahl SVNClient::diff() called with diff-cmd set
Hi, We've got a number of developers using the javahl bindings from Eclipse via subclipse. One of them recently reported a coredump against 1.10.3. I've also reproduced it with 1.9.7. The problem occurs when SVNClient::diff() is called with a diff-cmd defined in the user's ~/.subversion/config file. SVNClient::diff() calls svn_client_diff6() with the errstream explicitly set to NULL and the diff command in dwi->diff_cmd. Further down in the code, if diff_content_changed() from subversion/libsvn_client/diff.c is called, the NULL errstream is de-referenced with a call to svn_stream__aprfile(). I've put together a simple patch to avoid the null dereference, but I'm not 100% sure this is the correct solution. The code suggests to me that the intention is to allow the errstream parameter for svn_client_diff6() to be set to NULL, but maybe I'm misreading it. Is this the correct approach, and should I submit this patch for consideration? Thanks *** If you are not the intended recipient, please notify our Help Desk at Email information.soluti...@nats.co.uk immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person. NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system. Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments. NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL. ***
Re: Coredump when javahl SVNClient::diff() called with diff-cmd set
On 25.10.2018 12:41, BURT, Matthew J wrote: > > Hi, > > > > We’ve got a number of developers using the javahl bindings from Eclipse > > via subclipse. > > > > One of them recently reported a coredump against 1.10.3. I’ve also > > reproduced it with 1.9.7. > > > > The problem occurs when SVNClient::diff() is called with a diff-cmd > > defined in the user’s ~/.subversion/config file. > > > > SVNClient::diff() calls svn_client_diff6() with the errstream explicitly > > set to NULL and the diff command in dwi->diff_cmd. > > > > Further down in the code, if diff_content_changed() from > > subversion/libsvn_client/diff.c is called, the NULL errstream is > > de-referenced with a call to svn_stream__aprfile(). > > > > I’ve put together a simple patch to avoid the null dereference, but I’m > > not 100% sure this is the correct solution. The code suggests to me that > > the intention is to allow the errstream parameter for svn_client_diff6() > > to be set to NULL, but maybe I’m misreading it. > > > > Is this the correct approach, and should I submit this patch for > > consideration? > The docstring for svn_client_diff7 (..._diff6 was deprecated on trunk) doesn't say that outstream or errstream may be NULL; that's pretty definitive. This should be fixed in the native JavaHL code; either an actual stream should be used such that JavaHL users can read it (in this case I suspect that the JavaHL API would have to be upgraded), or a stream that ignores all writes should be used. -- Brane
Re: error
On Oct 24, 2018, at 13:00, Keith Wentworth wrote: > I got this error when I was updating my working copy: > > > D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c' > line 1039: assertion failed (move_dst_revision == expected_move_dst_revision > || status == svn_wc__db_status_not_present) The first thing I'd try is updating to a supported version. Subversion 1.8.x and earlier are end of life. https://subversion.apache.org/docs/release-notes/1.10.html#svn-1.8-deprecation
mod_dav_svn SVNUseUTF8 option not working
my subversion server is apache-2.4.34/event-MPM and subversion-1.9.7/mod_dav_svn configuration based on example from https://subversion.apache.org/docs/release-notes/1.8.html#hooks cat httpd.conf: SVNHooksEnv /etc/subversion/svnserve.conf SVNUseUTF8 On #not "yes" as example say cat /etc/subversion/svnserve.conf: [default] LANG = ru_RU.UTF-8 cat pre-commit: #!/bin/sh echo "Привет" >&2 pre-commit hook failed with message: [Error output could not be translated from the native locale to UTF-8.] this bug is https://issues.apache.org/jira/browse/SVN-2487 related. after some tracing of mod_dav_svn i find call to svn_utf_initialize2() from init() always does with conf->use_utf8=0. adding svn_utf_initialize2() to merge_server_config() fixes the problem. patch attached. --- subversion/mod_dav_svn/mod_dav_svn.c.orig<->2018-10-25 16:44:12.388287364 +0400 +++ subversion/mod_dav_svn/mod_dav_svn.c<-->2018-10-25 16:43:55.958287555 +0400 @@ -231,6 +231,8 @@ newconf->compression_level = child->compression_level; } . + newconf->use_utf8 = INHERIT_VALUE(parent, child, use_utf8); + svn_utf_initialize2(newconf->use_utf8, p); return newconf; } .
