Re: AW: dav issue with subversion-1.7.18 and httpd-2.4.10
Unsubsidised Cheers, Waseem Bukhari | CMer/ALM "Sent from Samsung Galaxy Note" Original message From: Markus Schaber Date:14/08/2014 11:58 (GMT+05:00) To: Subversion Subject: AW: dav issue with subversion-1.7.18 and httpd-2.4.10 Hi, Oli, Von: olli hauer [mailto:oha...@gmx.de] > On 2014-08-13 23:06, Mark Phippard wrote: > > Did you consider trying 1.8.x? I recall there were some 2.4.x fixes made. > Yes, but unluckily 1.8 is no option at the moment, also this could be a > potential problem for RHEL7 based systems (they deliver with svn 1.7 and > httpd 2.4) Just to rule out a potential misconception: If it only is about the server, you can update to self-compiled 1.8 packages, they are fully backwards compatible with version 1.7 clients (and even older ones). Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: AW: dav issue with subversion-1.7.18 and httpd-2.4.10
Unsubscribed Cheers, Waseem Bukhari | CMer/ALM "Sent from Samsung Galaxy Note" Original message From: Waseem Shahzad Date:14/08/2014 13:16 (GMT+05:00) To: Markus Schaber ,Subversion Subject: Re: AW: dav issue with subversion-1.7.18 and httpd-2.4.10 Unsubsidised Cheers, Waseem Bukhari | CMer/ALM "Sent from Samsung Galaxy Note" Original message From: Markus Schaber Date:14/08/2014 11:58 (GMT+05:00) To: Subversion Subject: AW: dav issue with subversion-1.7.18 and httpd-2.4.10 Hi, Oli, Von: olli hauer [mailto:oha...@gmx.de] > On 2014-08-13 23:06, Mark Phippard wrote: > > Did you consider trying 1.8.x? I recall there were some 2.4.x fixes made. > Yes, but unluckily 1.8 is no option at the moment, also this could be a > potential problem for RHEL7 based systems (they deliver with svn 1.7 and > httpd 2.4) Just to rule out a potential misconception: If it only is about the server, you can update to self-compiled 1.8 packages, they are fully backwards compatible with version 1.7 clients (and even older ones). Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
AW: Weird "Corrupt representation / Malformed representation header" Errors on fsfs repo.
Hi, Felix, you may have some success by restoring just the broken revision files by ones from the backup. You should replace both files - the one where the verification fails, and the file which is reported to have the malformed header. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > -Ursprüngliche Nachricht- > Von: felix.her...@t-systems.com [mailto:felix.her...@t-systems.com] > Gesendet: Donnerstag, 14. August 2014 07:30 > An: users@subversion.apache.org > Betreff: Weird "Corrupt representation / Malformed representation header" > Errors on fsfs repo. > > Hi, > > one of our large repositories went corrupt. Maybe someone can help. > On Aug 6th we had a Hardware crash of our svn server (mod_dav_svn) / svn > 1.7.11. > > This caused erros like: > [Fri Aug 08 14:00:01 2014] [error] [client ip.ip.ip.ip] (20014)Internal > error: Couldn't open rep-cache database [Fri Aug 08 14:00:01 2014] [error] > [client ip.ip.ip.ip] (20014)Internal error: -Couldn't perform atomic > initialization [Fri Aug 08 14:00:01 2014] [error] [client ip.ip.ip.ip] > (20014)Internal error: -database disk image is malformed, executing > statement 'PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;' > > This led me to: > https://mail-archives.apache.org/mod_mbox/subversion- > users/201401.mbox/%3c52d83701.5030...@reser.org%3E > > As Restoring a dump of the prod-repo would Take about >=8 hours I found a > workaround: > Taking a light older backup, restoring it on another place and replacing > the corrupt rep-cache.db on the production repo and restarting apache > httpd... > It seems to have worked. None of the error above appears anymore and the > rep-cache.db file grows. :) > > > > Sadly there is a new error where I don't know if the previous issue is > linked to this - that's why I explained it. :) > > Now the httpd-log presents Errors at Checkout like: > [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] Unable to deliver > content. [500, #0] [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] > could not prepare to read the file [500, #160004] [Wed Aug 13 17:32:27 > 2014] [error] [client ip.ip.ip.ip] Corrupt representation '76625 15736 24 > 1736 98aa6ec0f63f0cf7bc71f84cb15decf5 > 106c014975275e25ea0a7efab549472a8e32917e 77054-1ogo/_4x' [500, #160004] > [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] Malformed > representation header at /srv/svn/repo1/db/revs/76/76625:15751 [500, > #160004] > > Scanning the last revisions throws: > > for i in $(seq 77000 $(svnlook youngest /srv/svn/repo1)); do svnadmin > > verify /srv/svn/repo1 -r $i; done > [...] > * Verified revision 77014. > svnadmin: E160004: Corrupt representation '75477 1973 1105 7151 > a6e0d04828d8d5683c69faf7289c62e0 96f59510929937634de7c7fea27a005db91a31c9 > 77014-1ofa/_g' > svnadmin: E160004: Malformed representation header at > /srv/svn/repo1/db/revs/75/75477:1982 > * Verified revision 77016. > ... > * Verified revision 77047. > svnadmin: E160004: Corrupt representation '76625 48 29 7011 > c2fbbb12f89423213f919c53b926fa82 fc3aba63eaa5672fe664fd47ae5f6db780b9552c > 77047-1ogg/_a' > svnadmin: E160004: Malformed representation header at > /srv/svn/repo1/db/revs/76/76625:52 > * Verified revision 77049. > [...] > * Verified revision 77054. > svnadmin: E160004: Corrupt representation '76625 48 29 7011 > c2fbbb12f89423213f919c53b926fa82 fc3aba63eaa5672fe664fd47ae5f6db780b9552c > 77054-1ogo/_4w' > svnadmin: E160004: Malformed representation header at > /srv/svn/repo1/db/revs/76/76625:52 > * Verified revision 77056. > [...] > > So revisions: 77015, 77048 and 77055 are corrupt - others are okay - so > just commiting seems not to be the problem and thus I think it's not > linked to the first one. All corrupt commits come from the same user > account (authzn_svn_module) I am going to check his environment. > > Researching I found: > https://mail-archives.apache.org/mod_mbox/subversion- > dev/201010.mbox/%3C1286360504.2313.132.camel@edith%3E > > trying the script sadly throws: > ./fixer/fix-rev.py /srv/svn/repo1 77015 > Traceback (most recent call last): > File "./fixer/fix-rev.py", li
Re: SVN Property Value Size Limit
Le lundi 1 juillet 2013 15:17:05 UTC+2, 'Daniel Shahaf' a écrit : > > Use ra_serf then :-) > > Matthias Legeler wrote on Mon, Jul 01, 2013 at 12:04:12 +: > > Checkout with neon: property value truncated > > > > Checkout with serf (svn co --config-option > servers:global:http-library=serf URL): property value complete > > > > Matthias > > > > -Original Message- > > From: 'Daniel Shahaf' [mailto:dani...@elego.de ] > > Sent: Freitag, 28. Juni 2013 02:35 > > To: Matthias Legeler > > Cc: us...@subversion.apache.org > > Subject: Re: SVN Property Value Size Limit > > > > Matthias Legeler wrote on Thu, Jun 27, 2013 at 10:30:32 +: > > > 'svn propget --strict svn:mergeinfo ./ ' gets the first 7895 > > > characters 'svn propget --strict svn:mergeinfo URL' gets all 7959 > > > characters > > > > > > yes, 64 characters difference > > > > > > > Interesting, thanks. > > > > I guess the next step is to look at the response headers. (You can use > neon-debug-mask if you use neon, or wireshark/tcpdump if you don't use > > SSL.) In particular, whether the response includes the whole property, > and whether metadata (eg: Content-Length response header) matches the > response. > > > > BTW: does it happen under both serf and neon? (check 'svn --version' to > see which you have; use --config-option to switch the active library) > > > > Daniel > > > > > Matthias > > > > > > -Original Message- > > > From: Daniel Shahaf [mailto:dani...@elego.de ] > > > Sent: Donnerstag, 27. Juni 2013 12:18 > > > To: Matthias Legeler > > > Cc: 'us...@subversion.apache.org ' > > > Subject: Re: SVN Property Value Size Limit > > > > > > Matthias Legeler wrote on Thu, Jun 27, 2013 at 07:02:50 +: > > > > In our subversion repositories we have merged many many times. > > > > Now we have very large svn:mergeinfo property values (>8k). > > > > The problem is now, that if we make a svn checkout, the property > values will be truncated in the working copy by approximately 8k. > > > > The svn propget command at the working copy folder returns a > truncated value. > > > > > > Where does the truncation happen? Do you get only the first 8KB of > > > the property? Do you get everything except the last 8KB? What is the > > > offset from the point of truncation to the start and to the (true) end > > > of the property? (Is that offset a power of 2?) > > > > > > You can determine all that with 'svn propget --strict svn:mergeinfo > ./' > > > and 'svn propget --strict svn:mergeinfo URL'. > > > > > > Daniel > > > > > > > This occurs only for working copies there are created with the http > protocol over the svn apache. > > > > With the file protocol the property values are complete. > > > > > > > > My question: > > > > Is this a known behavior? > > > > Is this limited by a setting in the Apache/WebDAV/SVN configuration? > > > > > > > > regards, > > > > Matthias > > > > > Hi everybody. I have similar problem now with ra_serf as well. Subversion server version 1.5.2* (*r32768) Client version 1.8.8 (r1568071) using ra_serf 1.3.3 The offset between the local and server mergeinfo was 16 characters. We have found a way to fix the problem. To do so, we need to reduce the size of the mergeinfo. Here is how : - ssh to svn server - find the repository location (in this example, /srv/svn/repos/myrepo) - do a local checkout of the branch with too long mergeinfo (not through http !) svn co file:///srv/svn/repos/myrepo/myproject/branches/2.4 - check the mergeinfo o the problematic file to know where you can simplify the mergeinfo e.g. here we had a lot of merge from branch 2.0 for the file path/path/path/Foo.java /myproject/branches/2.0/path/path/path/Foo.java: 39126-43104,43469,44672,44705,44723,44736,44749,44794,44796,44805,44825,44831,44833,44852,44855,44865,44876,44879,44883,44887,44889,44905,44907,44912-44914,44919,44923,44947,44955,44957,44964,45007-45008,45069,45111,45114,45126,45128-45129,45142,45169,45202,45233,45341,45349,45351,45409,45425,45441,45460,45564,45568,45573,45575,45594-45595,45603,45626,45637,45654,45785,45827-45829,45832,45868,45871,45874,45877,45891,45917,45965,46000,46010,46014,46018,46024,46026,46030-46031,46038,46060,46073,46094,46109,46123,46130,46134,46159,46186,46190,46197,46210,46270,46304,46360,46363,46442-46443,46451,46470,46477-46478,46480-46481,46486-46488,46506,46509,46520,46539,46556,46561,46574,46582,46590,46595,46599,46604,46606,46752-46753,46755,46779-46780,46851-46852,46859,46864,46886,46903-46904,46923,46929,46984-46985,47011,47022,47040,47105,47120,47182,47205,47207-47208,47211,47238,47247,47253,47258,47288,47300,47302,47358,47377,47381,47407,47409-47410,47435,47514,47516,47522,47524,47536,47544,47553,47598,47605,47611,47615,47619,47622,47654,47711,47764,47923,47936,48023,48096,48164,48170-48171,48183,48290,48649,48666-48667,48755,48829,48897,48959,48962-48963,48982,48989,48991,49060,49068,49174,49184-49185,49205,49
AW: Weird "Corrupt representation / Malformed representation header" Errors on fsfs repo.
Hi, thank you for your reply. I really appreciate that. Sadly I found out I can not restore it as the backup via svnadmin dump stops at the corrupted revision... It seems I am going to do it as follows: 1 creating incremental Dumpfiles leaving the corrupted revisions 2 loading the repo with the dumpfiles (in correct order) into a new repo-space like /srv/svn/repo1_fixed 3 moving the /srv/svn/repo1 to /srv/svn/repo1_corrupt 4 and doing a svnadmin hotcopy /srv/svn/repo1_fixed to /srv/svn/repo1 (and doing chown etc. and using the original authz...) I've read that moving by "mv" in step 4 instead of that hotcopy might cause trouble... is that right? Otherwise this moving might be a lot faster. Today I measured the svn load of this 77014 revisions and it took 18 hours. :/ Regards, Felix -Ursprüngliche Nachricht- Von: Markus Schaber [mailto:m.scha...@codesys.com] Gesendet: Donnerstag, 14. August 2014 10:31 An: Herzog, Felix; users@subversion.apache.org Betreff: AW: Weird "Corrupt representation / Malformed representation header" Errors on fsfs repo. Hi, Felix, you may have some success by restoring just the broken revision files by ones from the backup. You should replace both files - the one where the verification fails, and the file which is reported to have the malformed header. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > -Ursprüngliche Nachricht- > Von: felix.her...@t-systems.com [mailto:felix.her...@t-systems.com] > Gesendet: Donnerstag, 14. August 2014 07:30 > An: users@subversion.apache.org > Betreff: Weird "Corrupt representation / Malformed representation header" > Errors on fsfs repo. > > Hi, > > one of our large repositories went corrupt. Maybe someone can help. > On Aug 6th we had a Hardware crash of our svn server (mod_dav_svn) / svn > 1.7.11. > > This caused erros like: > [Fri Aug 08 14:00:01 2014] [error] [client ip.ip.ip.ip] (20014)Internal > error: Couldn't open rep-cache database [Fri Aug 08 14:00:01 2014] [error] > [client ip.ip.ip.ip] (20014)Internal error: -Couldn't perform atomic > initialization [Fri Aug 08 14:00:01 2014] [error] [client ip.ip.ip.ip] > (20014)Internal error: -database disk image is malformed, executing > statement 'PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;' > > This led me to: > https://mail-archives.apache.org/mod_mbox/subversion- > users/201401.mbox/%3c52d83701.5030...@reser.org%3E > > As Restoring a dump of the prod-repo would Take about >=8 hours I found a > workaround: > Taking a light older backup, restoring it on another place and replacing > the corrupt rep-cache.db on the production repo and restarting apache > httpd... > It seems to have worked. None of the error above appears anymore and the > rep-cache.db file grows. :) > > > > Sadly there is a new error where I don't know if the previous issue is > linked to this - that's why I explained it. :) > > Now the httpd-log presents Errors at Checkout like: > [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] Unable to deliver > content. [500, #0] [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] > could not prepare to read the file [500, #160004] [Wed Aug 13 17:32:27 > 2014] [error] [client ip.ip.ip.ip] Corrupt representation '76625 15736 24 > 1736 98aa6ec0f63f0cf7bc71f84cb15decf5 > 106c014975275e25ea0a7efab549472a8e32917e 77054-1ogo/_4x' [500, #160004] > [Wed Aug 13 17:32:27 2014] [error] [client ip.ip.ip.ip] Malformed > representation header at /srv/svn/repo1/db/revs/76/76625:15751 [500, > #160004] > > Scanning the last revisions throws: > > for i in $(seq 77000 $(svnlook youngest /srv/svn/repo1)); do svnadmin > > verify /srv/svn/repo1 -r $i; done > [...] > * Verified revision 77014. > svnadmin: E160004: Corrupt representation '75477 1973 1105 7151 > a6e0d04828d8d5683c69faf7289c62e0 96f59510929937634de7c7fea27a005db91a31c9 > 77014-1ofa/_g' > svnadmin: E160004: Malformed representation header at > /srv/svn/repo1/db/revs/75/75477:1982 > * Verified revision 77016. > ... > * Verified revision 77047. > svnadmin: E160004: Corrupt representation '76625 48 29 7011 > c2fbbb12f89423213f919c53b92
RE: svnrdump problem
>> Shouldn't the svnrdump issue be investigated regardless? >It would help if you provided more information: which version of Subversion >are you using? What sort of changes does the problem revision contain? Which >>files are not being closed? Run "lsof" on the process when it is running, it lists the open file handles. It's a bit easier to figure out what files its opening than strace. This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives.
switch error
I received the following error while trying to use "switch": Matthew Hoffman Software Engineer ZK Celltest, Inc m...@zk.com --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8713: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK ---
