Re: FW: Error with svn
On 20.12.2018 17:59, Branko Čibej wrote: > On 20.12.2018 13:41, Руслан Самигуллин wrote: >> I have running Subversion on 64-bit Win and on 32-bit Win. Maybe I am wrong >> for this command, I found it on this web site: >> https://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale > > This answer on StackOverflow is only for Debian Linux and related > (Ubuntu, Mint, etc.). It won't work on Windows. > > >> I said that I don`t know how to fix my problem on Win. Please help me. What >> command is needed to set “variable LANG” or another way to solve this >> problem? > For some reason your regional setting on Windows are not correct. > Subversion uses 'setlocale(LC_ALL, "")' and if that fails, > 'setlocale(LC_CTYPE, "")'. This should always work on Windows; I don't > know why it doesn't. > > See: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale > > Are you sure you're using a native Windows binary of Subversion, not > something built for Cygwin or WSL? > > > -- Brane > > >> From: Branko Čibej >> Sent: Thursday, 20 December 2018 15:17 >> To: Руслан Самигуллин; users@subversion.apache.org >> Subject: Re: Error with svn >> >> On 20.12.2018 11:31, Руслан Самигуллин wrote: >>> Hello! >>> >>> I have a problem with svn. The problem appears when I run svn.exe. I have >>> Windows 10 x64, and this problem appears in Win10 x32. >>> >>> The text from the console window is reduced below: >>> >>> svn: warning: cannot set LC_CTYPE locale >>> svn: warning: environment variable LANG is not set >>> svn: warning: please check that your locale name is correct >>> >>> I found that have to install language pack like that: (sudo apt-get install >>> language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t >>> know how to do it. And in what catalogue I must write the command to >>> install in cmd? >> I'm confused: You say you're running 32-bit Subversion binaries on >> 64-bit Windows, but then you show the proposed 'fix' as commands that >> would work on some Debian-based Linux distribution? That can't be right. >> Where did you get those commands from? >> Руслан, please respond here instead of starting a new thread with the same topic. -- Brane
Re: FW: Error with svn
On 20.12.2018 13:41, Руслан Самигуллин wrote: > I have running Subversion on 64-bit Win and on 32-bit Win. Maybe I am wrong > for this command, I found it on this web site: > https://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale This answer on StackOverflow is only for Debian Linux and related (Ubuntu, Mint, etc.). It won't work on Windows. > I said that I don`t know how to fix my problem on Win. Please help me. What > command is needed to set “variable LANG” or another way to solve this problem? For some reason your regional setting on Windows are not correct. Subversion uses 'setlocale(LC_ALL, "")' and if that fails, 'setlocale(LC_CTYPE, "")'. This should always work on Windows; I don't know why it doesn't. See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale Are you sure you're using a native Windows binary of Subversion, not something built for Cygwin or WSL? -- Brane > From: Branko Čibej > Sent: Thursday, 20 December 2018 15:17 > To: Руслан Самигуллин; users@subversion.apache.org > Subject: Re: Error with svn > > On 20.12.2018 11:31, Руслан Самигуллин wrote: >> Hello! >> >> I have a problem with svn. The problem appears when I run svn.exe. I have >> Windows 10 x64, and this problem appears in Win10 x32. >> >> The text from the console window is reduced below: >> >> svn: warning: cannot set LC_CTYPE locale >> svn: warning: environment variable LANG is not set >> svn: warning: please check that your locale name is correct >> >> I found that have to install language pack like that: (sudo apt-get install >> language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t >> know how to do it. And in what catalogue I must write the command to install >> in cmd? > > I'm confused: You say you're running 32-bit Subversion binaries on > 64-bit Windows, but then you show the proposed 'fix' as commands that > would work on some Debian-based Linux distribution? That can't be right. > Where did you get those commands from?
FW: Error with svn
I have running Subversion on 64-bit Win and on 32-bit Win. Maybe I am wrong for this command, I found it on this web site: https://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale I said that I don`t know how to fix my problem on Win. Please help me. What command is needed to set “variable LANG” or another way to solve this problem? Ruslan From: Branko Čibej Sent: Thursday, 20 December 2018 15:17 To: Руслан Самигуллин; users@subversion.apache.org Subject: Re: Error with svn On 20.12.2018 11:31, Руслан Самигуллин wrote: > Hello! > > I have a problem with svn. The problem appears when I run svn.exe. I have > Windows 10 x64, and this problem appears in Win10 x32. > > The text from the console window is reduced below: > > svn: warning: cannot set LC_CTYPE locale > svn: warning: environment variable LANG is not set > svn: warning: please check that your locale name is correct > > I found that have to install language pack like that: (sudo apt-get install > language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t > know how to do it. And in what catalogue I must write the command to install > in cmd? I'm confused: You say you're running 32-bit Subversion binaries on 64-bit Windows, but then you show the proposed 'fix' as commands that would work on some Debian-based Linux distribution? That can't be right. Where did you get those commands from? -- Brane
Re: Error with svn
On 20.12.2018 11:31, Руслан Самигуллин wrote: > Hello! > > I have a problem with svn. The problem appears when I run svn.exe. I have > Windows 10 x64, and this problem appears in Win10 x32. > > The text from the console window is reduced below: > > svn: warning: cannot set LC_CTYPE locale > svn: warning: environment variable LANG is not set > svn: warning: please check that your locale name is correct > > I found that have to install language pack like that: (sudo apt-get install > language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t > know how to do it. And in what catalogue I must write the command to install > in cmd? I'm confused: You say you're running 32-bit Subversion binaries on 64-bit Windows, but then you show the proposed 'fix' as commands that would work on some Debian-based Linux distribution? That can't be right. Where did you get those commands from? -- Brane
Error with svn
Hello! I have a problem with svn. The problem appears when I run svn.exe. I have Windows 10 x64, and this problem appears in Win10 x32. The text from the console window is reduced below: svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LANG is not set svn: warning: please check that your locale name is correct I found that have to install language pack like that: (sudo apt-get install language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t know how to do it. And in what catalogue I must write the command to install in cmd? Best regards, Ruslan Samigullin
Merge tracking (cherry-pick) error in Svn ... looking for confirmation before filing a JIRA ticket.
Except I filed the ticket instead of reading the ticket-filing instructions, so ‘before' really is ‘after' – oops: https://issues.apache.org/jira/browse/SVN-4635 Reproduction: git clone https://github.com/paul-hammant/subversion_testing.git cd subversion_testing ./reset.sh ./server.sh ./test_of_out_order_merges_back_the_original_branch.sh Does this finished or choke on a merge conflict for you? If the same scripts ported to Perforce, Git and Mercurial and the same sequence of events works fine. The code for those is on branches in that Git repo. I wrote blog entries too for the experience, but it’s probably not necessary to link to them here. - Paul
Error 10179 / SVN loses authentication during session
Hello, We use SVN with a small team (3 developers), and we've been experiencing some strange issues lately. We use tortoiseSVN to connect to out repository from Windows explorer, and some of the time some of our actions get rejected, asking us to log in again. As I also received an error, perhaps these two are related. (see below for full error copy) When actually using the provided login dialog, we never actually get access. (even checking the remember me checkbox does not solve it.) All three of our users have this issue, but not all of the time. For example, this morning I was allowed to update to the latest versions, and perform some searches through the logs (code review). After a couple of files I suddenly got the login dialog, after which the error popped up. Workaround: Some of the time, I've managed to actually continue my work by resetting my password in Assembla (through the website). But that does not work consistently. Attempts made to solve it on our end: -Install the latest version of SVN/Tortoise -Removing the authentication files (so Tortoise could regenerate them) What can we do to fix this? Kind regards, Robin Oudhuis --- 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.9.0\ext\subversion\subversion\libsvn_wc\wc_db.c' line 10179: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK ---
Re: Error 10179 / SVN loses authentication during session
Hi Robin, Hello, We use SVN with a small team (3 developers), and we’ve been experiencing some strange issues lately. We use tortoiseSVN to connect to out repository from Windows explorer, and some of the time some of our actions get rejected, asking us to log in again. As I also received an error, perhaps these two are related. (see below for full error copy) When actually using the provided login dialog, we never actually get access. (even checking the remember me checkbox does not solve it.) All three of our users have this issue, but not all of the time. For example, this morning I was allowed to update to the latest versions, and perform some searches through the logs (code review). After a couple of files I suddenly got the login dialog, after which the error popped up. Workaround: Some of the time, I’ve managed to actually continue my work by resetting my password in Assembla (through the website). But that does not work consistently. Attempts made to solve it on our end: -Install the latest version of SVN/Tortoise -Removing the authentication files (so Tortoise could regenerate them) What can we do to fix this? Since nobody replied yet, I'd like to give you at least some standard answers. I see that you are using TSVN 1.9.0. Please note that as of today the latest available version is 1.9.2. It might be worth a try to upgrade to this and retest the issue. With regards to the error u reported, I think to remember this type of error at least in one case was (or still is?) related to a situation where TSVN doesn't set an absolute path where SVN expects that. I'm not sure about the state of this issue (it might have been long resolved and I don't have a reference at hand). But maybe u could try to get some better help on the tortoiseSVN user list when you point out: - where your working directory is located (path, etc.) - the path to your repository which the working copy is set to If you can reproduce the issue using the default SVN command line client, it might raise ur chances of someone providing further support on this list too. Regards, Stefan
Strange error when svn update --set-depth
Hello! I am using the command line client of the latest 1.8 tortoise SVN on windows 7 to change the depth of a working copy. The subdirectory ACS64-A8 contains only an svn:external. Extending depth to include that said external works flawlessly. But when I remove it, I get two warnings and an error (Zugriff verweigert is Access denied): D:\PRJ\RDA\Main\Imagessvn update --set-depth empty ACS64-A8 Updating 'ACS64-A8': Removed external 'ACS64-A8\images': Can't check path 'D:\PRJ\RDA\Main\Images\ACS64-A8\images\.svn': Zugriff verweigert svn: warning: W20: Error handling externals definition for 'ACS64-A8\images': svn: warning: W720005: Can't check path 'D:\PRJ\RDA\Main\Images\ACS64-A8\images\.svn': Zugriff verweigert Updated to revision 3872. svn: E205011: Failure occurred processing one or more externals definitions but strange enough: the directory images is gone. So I get an error for an action that looks like it succeeded finally. Could the virus scanner delay a delete action, so that svn *thinks* it didn't work? (svn, version 1.8.14 (r1692801)compiled Aug 2 2015, 17:48:46 on x86-microsoft-windows) Mit freundlichen Grüßen Dr. Hartmut Niemann Siemens AG Mobility MO MLT LM EN CCI 1 Werner-von-Siemens-Str. 67 91052 Erlangen, Deutschland Tel.: +49 9131 7-34264 Fax: +49 9131 7-26254 mailto:hartmut.niem...@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Re: Strange error when svn update --set-depth
On Aug 24, 2015, at 11:12 AM, Niemann, Hartmut wrote: I am using the command line client of the latest 1.8 tortoise SVN on windows 7 to change the depth of a working copy. The subdirectory ACS64-A8 contains only an svn:external. Extending depth to include that said external works flawlessly. But when I remove it, I get two warnings and an error (Zugriff verweigert is Access denied): D:\PRJ\RDA\Main\Imagessvn update --set-depth empty ACS64-A8 Updating 'ACS64-A8': Removed external 'ACS64-A8\images': Can't check path 'D:\PRJ\RDA\Main\Images\ACS64-A8\images\.svn': Zugriff verweigert svn: warning: W20: Error handling externals definition for 'ACS64-A8\images': svn: warning: W720005: Can't check path 'D:\PRJ\RDA\Main\Images\ACS64-A8\images\.svn': Zugriff verweigert Updated to revision 3872. svn: E205011: Failure occurred processing one or more externals definitions but strange enough: the directory images is gone. So I get an error for an action that looks like it succeeded finally. Could the virus scanner delay a delete action, so that svn *thinks* it didn’t work? (svn, version 1.8.14 (r1692801)compiled Aug 2 2015, 17:48:46 on x86-microsoft-windows) Virus scanners definitely can interfere with Subversion. Have you tried turning your virus scanner off, or telling it not to scan the directory containing your working copy(ies)?
Re: svn: E155011 out of date error and svn: E160020 already exists error
Hi James, the error sounds to me as if the file you wanted to add was already commited. Did you try svn up before svn commit? Regards, Stefan I renamed a package (folder name) and then renamed two files under it (the renamed folder). Then I use kdesvn to do commit which will add and then commit, I think. I got the attached error. Then I tried the following command line commands but no luck: svn up --force theFolder, svn commit -m messages . Is there a way to fix it or I have to checkout a fresh copy and copy over the existing one? I am using svn 1.8.10 under Fedora 20. thanks, James $ svn commit -m rename scmgmt package to exmgmt Adding com/uiapp/exmgmt/ExMgmtMgr.java svn: E155011: Commit failed (details follow): svn: E155011: File '/home//0-workspace/OC/trunk/latest/src/com/uiapp/exmgmt/ExMgmtMgr.java' is out of date svn: E160020: File 'com/uiapp/exmgmt/ExMgmtMgr.java' already exists
svn: E155011 out of date error and svn: E160020 already exists error
I renamed a package (folder name) and then renamed two files under it (the renamed folder). Then I use kdesvn to do commit which will add and then commit, I think. I got the attached error. Then I tried the following command line commands but no luck: svn up --force theFolder, svn commit -m messages .Is there a way to fix it or I have to checkout a fresh copy and copy over the existing one? I am using svn 1.8.10 under Fedora 20. thanks,James $ svn commit -m rename scmgmt package to exmgmt Adding com/uiapp/exmgmt/ExMgmtMgr.java svn: E155011: Commit failed (details follow): svn: E155011: File '/home//0-workspace/OC/trunk/latest/src/com/uiapp/exmgmt/ExMgmtMgr.java' is out of date svn: E160020: File 'com/uiapp/exmgmt/ExMgmtMgr.java' already exists
Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64
I'm not sure if this is a known error, but as I tried with TortoiseSVN and SlikSvn, I'm positive it's an upstream problem: I use Windows 8.1 x64 and wanted to checkout the FreeBSD docs repositories.
Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64
I'm not sure if this is a known error, but as I tried with TortoiseSVN and SlikSvn, I'm positive it's an upstream problem: I use Windows 8.1 x64 and wanted to checkout the FreeBSD docs repositories. svn co https://svn0.us-west.FreeBSD.org/doc/ This reproducibly leads to this error: svn: E235000: In Datei »..\..\..\subversion\libsvn_wc\update_editor.c«, Zeile 1550: Assert-Anweisung schlug fehl (action == svn_wc_conflict_action_delete) (Yes, I'm German. Hope that's not a problem. ;-)) Maybe some ideas? Regards.
Re: Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64
On 17.01.2015 19:18, tux. wrote: I'm not sure if this is a known error, but as I tried with TortoiseSVN and SlikSvn, I'm positive it's an upstream problem: I use Windows 8.1 x64 and wanted to checkout the FreeBSD docs repositories. svn co https://svn0.us-west.FreeBSD.org/doc/ This reproducibly leads to this error: svn: E235000: In Datei »..\..\..\subversion\libsvn_wc\update_editor.c«, Zeile 1550: Assert-Anweisung schlug fehl (action == svn_wc_conflict_action_delete) (Yes, I'm German. Hope that's not a problem. ;-)) Maybe some ideas? Are you sure you did a fresh checkout? As far as I can see, this assertion could happen under certain circumstances during an update, but not during a checkout, unless the server is sending an invalid response. -- Brane
RE: Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64
-Original Message- From: tux. [mailto:z...@tuxproject.de] Sent: zaterdag 17 januari 2015 19:18 To: users@subversion.apache.org Subject: Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64 I'm not sure if this is a known error, but as I tried with TortoiseSVN and SlikSvn, I'm positive it's an upstream problem: I use Windows 8.1 x64 and wanted to checkout the FreeBSD docs repositories. svn co https://svn0.us-west.FreeBSD.org/doc/ This reproducibly leads to this error: svn: E235000: In Datei ..\..\..\subversion\libsvn_wc\update_editor.c, Zeile 1550: Assert-Anweisung schlug fehl (action == svn_wc_conflict_action_delete) (Yes, I'm German. Hope that's not a problem. ;-)) What Brank said: This assertion should only be triggerable from an 'svn update', so most likely the directory already existed before you started the checkout. (This will continue the checkout, as an update) This would be the interesting part, as we haven't got a bug report for this assertion that allowed us to reproduce this problem. Do you have a more specific path to checkout? This command checks out the entire repository; something we don't call good practice (As it breaks things like cheap copies, etc)... and it certainly is a slow way to reproduce a problem. I'm busy checking out from this url for about an hour now, and I have a multi GB working copy, but I'm not done yet and haven't seen an error yet. Bert Maybe some ideas? Regards.
Re: Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64
On 18.01.2015 13:44, Bert Huijben wrote: -Original Message- From: tux. [mailto:z...@tuxproject.de] Sent: zaterdag 17 januari 2015 19:18 To: users@subversion.apache.org Subject: Possible (reproducible) ASSERT error with SVN 1.8.11 on Windows 8.1 x64 I'm not sure if this is a known error, but as I tried with TortoiseSVN and SlikSvn, I'm positive it's an upstream problem: I use Windows 8.1 x64 and wanted to checkout the FreeBSD docs repositories. svn co https://svn0.us-west.FreeBSD.org/doc/ This reproducibly leads to this error: svn: E235000: In Datei ..\..\..\subversion\libsvn_wc\update_editor.c, Zeile 1550: Assert-Anweisung schlug fehl (action == svn_wc_conflict_action_delete) (Yes, I'm German. Hope that's not a problem. ;-)) What Brank said: This assertion should only be triggerable from an 'svn update', so most likely the directory already existed before you started the checkout. (This will continue the checkout, as an update) This would be the interesting part, as we haven't got a bug report for this assertion that allowed us to reproduce this problem. Do you have a more specific path to checkout? This command checks out the entire repository; something we don't call good practice (As it breaks things like cheap copies, etc)... and it certainly is a slow way to reproduce a problem. I'm busy checking out from this url for about an hour now, and I have a multi GB working copy, but I'm not done yet and haven't seen an error yet. I tried the checkout eariler today with 1.8.11 on OSX, and got no assertion. Same happens when I retry the same command when the working copy already exists. Since this part of the code is not platform specific in any way, I have to assume that there's some specific precondition that's not described in the original report. -- Brane
get error on svn -u status
I just moved a subversion repository from an ubuntu linux 12.04 server running subversion 1.6.12 to an ubuntu Linux 14.04.1 server running subversion 1.8.8. I have been able to export the code to an ubuntu 14.04.1 client running subversion 1.8.8 and when I do a svn -u status W155007: ‘home/mkerwin/src/trunk/c/eco’ is not a working copy I get this error no matter what directory I do it in and it used to work fine before the move when we were running Ubuntu 12.04 clients with the old repository. We are using apache2 with ssl for old and new repository. Michael Kerwin mich...@kerputer.com
Re: get error on svn -u status
Hello, On 5 Sep 2014, at 19:41, Michael Kerwin mich...@kerputer.com wrote: I have been able to export the code to an ubuntu 14.04.1 client running subversion 1.8.8 and when I do a svn -u status W155007: ‘home/mkerwin/src/trunk/c/eco’ is not a working copy If you ran svn export rather than svn checkout, the result will indeed not be a working copy on which svn status would work. Run it on a working copy created by svn checkout. Andreas
Still facing authorization failed error in SVN
Hello there, Few days back, I had posted issue related to authorization failed error in SVN. I am writing the detailed about that, the reason I had browsed N number of solutions and could not found proper solution. Detailed configuration of my system: Operating System: Windows 7 Ultimate 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_rtm.101119-1850) Apache tomcat version: 7.3 CollabNetSubversion-server-1.6.17-4.win32 (server version) TortoiseSVN-1.7.1.22161-x64-svn-1.7.1.msi (client version) These are the software I had installed as of now and trying the setting the working copy of subversion. Before writing the email I had tried with Setup-Subversion-1.8.3 but, no result. With best regards, Vikas Waghmare, TechVision software solution, Skype:vikas.waghmare1 mobile phone:+919922885014
Re: Error during 'svn export' over http with serf 1.3.1
On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing.
Re: Error during 'svn export' over http with serf 1.3.1
That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://. Using: 1.8.3 client (serf 1.3.1) Connecting to: repo with db format 6 (I dumped and loaded the format 4 repo to a new format 6 again) Seems the path is significant in what errors I receive. $ svn log http://gemini2/svn/www Ran this command 50 times with no errors. $ svn log http://gemini2/svn/www/trunk Ran this 50 times and got the following error 5 times. Interesting to note that commit 496 was made on a branch. svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/www/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/www/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '496 2752 110 0 8733d74a90f550a19dddad89a54718fa' $ svn log http://gemini2/svn/www/branches Ran this 15 times and got the following error 12 times. svn: E120104: ra_serf: An error occurred during decompression
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 12:17 PM, Lieven Govaerts lieven.govae...@gmail.com wrote: On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://. Using: 1.8.3 client (serf 1.3.1) Connecting to: repo with db format 6 (I dumped and loaded the format 4 repo to a new format 6 again) Seems the path is significant in what errors I receive. $ svn log http://gemini2/svn/www Ran this command 50 times with no errors. $ svn log http://gemini2/svn/www/trunk Ran this 50 times and got the following error 5 times. Interesting to note that commit 496 was made on a branch. svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/www/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/www/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '496 2752 110 0 8733d74a90f550a19dddad89a54718fa' The origin of these two errors is server side, they are only reported on the client. Do you see anything special in the server access and error logs? We have seen a case were http headers were dropped (by a virus scanner) leading to strange requests. $ svn log http://gemini2/svn/www/branches Ran this 15 times and got the following error 12 times. svn: E120104: ra_serf: An error occurred during decompression I suppose these are similar to other reports already under investigation (and I can reproduce myself), so let's focus on the server errors here. Lieven Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. [Wed Sep 11 11:24:42.592421 2013] [dav:error] [pid 5918] [client 192.168.0.139:53889] Provider encountered an error while streaming a REPORT response
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors.
Re: Error during 'svn export' over http with serf 1.3.1
On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 3:04 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. Here is a new one. Running 1.8.3 client against 1.8.1 server. repo is format 4. svnadmin verity reports no problems. $ svn ls http://gemini2/svn/roclock/trunk svn: E24: Could not convert '###error###' into a number error.log on server logs this: [Wed Sep 11 18:40:14.393500 2013] [:error] [pid 14479] (160004)APR does not understand this error code: [client 192.168.0.139:55525] Can't fetch proplist of '/trunk': Corrupt representation '137 5727 30 0 bccc4074133de2a54dfaee6dfacbfede' Now when I run my 1.7.11 client against the same repo it works fine. This is reproducible every time. I created a new repo (format 6) dumped/loaded. The 1.8.3 client works fine against the new repo.
Re: Error during 'svn export' over http with serf 1.3.1
Curt Sellmer sellmer...@gmail.com writes: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin philip.mar...@wandisco.com wrote: Curt Sellmer sellmer...@gmail.com writes: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:04 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin philip.mar...@wandisco.com wrote: Curt Sellmer sellmer...@gmail.com writes: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks. I just bounced the apache server and it did indeed clear up the problem. I can now access the repo with both clients. Thank you. I apologize that I didn't realize that the web server had to be bounced. Not sure that was in the docs anywhere? This may well be the cause of the previous problems as I had a script that would create a new repo, dump | load to it, then rename the new repo with the original repo's name. I'll keep testing with the new found knowledge.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:19 PM, Curt Sellmer sellmer...@gmail.com wrote: You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks. I just bounced the apache server and it did indeed clear up the problem. I can now access the repo with both clients. Thank you. I apologize that I didn't realize that the web server had to be bounced. Not sure that was in the docs anywhere? This may well be the cause of the previous problems as I had a script that would create a new repo, dump | load to it, then rename the new repo with the original repo's name. I'll keep testing with the new found knowledge. Since bouncing the apache server I am not seeing any errors with any of the repos. Classic case of user error. I really appreciate all of your help and quick responses. Thanks, Curt
Re: Error during 'svn export' over http with serf 1.3.1
[ Please use reply all to keep the list in the loop -- I'm sending this to users@ rather than dev@, because other users might also be interested and/or can chime in if someone has similar issues. Also, this list prefers bottom-posting or inline replying, so I've rearranged to put your reply at the bottom. More below. ] On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3 client, and see if it reproduces. Then, perhaps you can also update your server to 1.8.3, just to be sure that you're not chasing something that has already been fixed
Re: Error during 'svn export' over http with serf 1.3.1
On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com wrote: [ Please use reply all to keep the list in the loop -- I'm sending this to users@ rather than dev@, because other users might also be interested and/or can chime in if someone has similar issues. Also, this list prefers bottom-posting or inline replying, so I've rearranged to put your reply at the bottom. More below. ] On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3
Re: Error during 'svn export' over http with serf 1.3.1
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com wrote: [ Please use reply all to keep the list in the loop -- I'm sending this to users@ rather than dev@, because other users might also be interested and/or can chime in if someone has similar issues. Also, this list prefers bottom-posting or inline replying, so I've rearranged to put your reply at the bottom. More below. ] On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3 client, and see if it reproduces. Then, perhaps you can also update your
Re: Error during 'svn export' over http with serf 1.3.1
On 9/10/13 2:31 PM, Curt Sellmer wrote: After giving it more time I can now reproduce the problem with both version 1.8.0 and 1.8.3 of the client. And I have now seen the problem with both the older and newer versions of the repository. Very hard to debug as it does not seem to follow any pattern. As I posted earlier, it was working without a hitch for several minutes of testing. Then I went through a period where it failed more than succeeded. A bit later it was failing more sporadically, regardless of which version of the client. I can say this with complete confidence, but it seems that the 1.8.3 client fails more with the old repo and the 1.8.0 client fails more with the new repo, but I can verify that the both have failed with both repos. With 1.8.0 I see the following errors (separate runs): svn: E160004: Corrupt node-revision '3-1.0-489.r495/2100' svn: E120104: ra_serf: An error occurred during decompression With 1.8.3 I get the same errors but the reporting for the Corrupt node is different: svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/svn/www/!svn/rvr/496/branches/rails-3.2' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '3-1.0-489.r495/2100' And again both errors can be seen against both repos. I ran svnadmin verify again against both repos with no errors reported. Can you please post the output of: svn --version --verbose If that command doesn't show that you're using serf 1.3.1 can you please rebuild using the 1.3.1 version of the serf library? The minimum required serf version is still 1.2.1 in 1.8.0-1.8.3. Serf 1.3.0 and 1.3.1 have fixed quite a few bugs that impact Subversion users, but they also switched to using the SCons build system that may present some trouble for people building. Since most of the issues fixed in serf are relatively rare we haven't raised the minimum required version. If after you've upgraded serf to 1.3.1 and if you are still having the issue it could still either be a bug in Subversion or a bug in Serf.
Re: Error during 'svn export' over http with serf 1.3.1
I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' -- Here is the new --version info $ svn --version --verbose svn, version 1.8.3 (r1516576) compiled Sep 10 2013, 22:18:41 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.1 - handles 'http' scheme - handles 'https' scheme System information: * running on x86_64-apple-darwin12.4.0 - Mac OS X 10.8.4 Mountain Lion, build 12E55 * linked dependencies: - APR 1.4.5 (compiled with 1.4.5) - APR-Util 1.3.12 (compiled with 1.3.12) - SQLite 3.8.0.2 (compiled with 3.8.0.2) * loaded shared libraries: - /Users/curt/Downloads/subversion-1.8.3/subversion/svn/.libs/svn (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_client/.libs/libsvn_client-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_wc/.libs/libsvn_wc-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra/.libs/libsvn_ra-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_diff/.libs/libsvn_diff-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_repos/.libs/libsvn_repos-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs/.libs/libsvn_fs-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.0.dylib (Intel 64-bit) - /usr/lib/libsasl2.2.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_serf/.libs/libsvn_ra_serf-1.0.dylib (Intel 64-bit) - /Users/curt/local/lib/libserf-1.3.0.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_delta/.libs/libsvn_delta-1.0.dylib (Intel 64-bit) - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_subr/.libs/libsvn_subr-1.0.dylib (Intel 64-bit) - /usr/lib/libexpat.1.dylib (Intel 64-bit) - /usr/lib/libz.1.dylib (Intel 64-bit) - /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit) - /usr/local/lib/libmagic.1.dylib (Intel 64-bit) - /usr/lib/libaprutil-1.0.dylib (Intel 64-bit) - /usr/lib/libapr-1.0.dylib (Intel 64-bit) - /usr/lib/libSystem.B.dylib (Intel 64-bit) - /usr/lib/libiconv.2.dylib (Intel 64-bit) - /usr/lib/libsqlite3.dylib (Intel 64-bit
Re: Proxy error on SVN 1.8.1
Hi, On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier guillaume.lasn...@hybris.com wrote: Hi all, When issuing the following command, I get the following error: $ svn -v log svn: E120107: Unable to connect to a repository at URL 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform' svn: E120107: Error running context: The proxy server returned an error while setting up the SSL tunnel. I was able to reproduce this issue with serf trunk, reported this as serf issue 120: https://code.google.com/p/serf/issues/detail?id=120 The trigger is that the proxy server is configured to close the connection after each response. In apache that would be the KeepAlive Off flag. It's not clear what the actual root cause is, but now that we can reproduce it we should be able to fix this soon. thanks for the provided info! Lieven I am using subversion 1.8.1 on Mac OS X installed with homebrew. I have configured the proxy the following way in ~/.subversion/servers : [groups] # group1 = *.collab.net # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com mygroup = *.myhost.mydomain # Information for my group: [mygroup] http-proxy-host = 192.168.xxx.xxx http-proxy-port = 1234 http-proxy-username = john http-proxy-password = doe This configuration used to work with subversion 1.7. Do have any idea? -- Guillaume Lasnier
Re: Proxy error on SVN 1.8.1
Lieven Govaerts wrote on Mon, Aug 05, 2013 at 09:03:13 +0200: Now I see that homebrew provides serf 1.2.1, also for Subversion 1.8.1 (*). Serf 1.3.0 is available which includes many fixes for the ssl tunnel and authentication code. So I propose that you test with serf 1.3.0 first. You'll have to build svn and serf manually or wait for the homebrew project to update serf to 1.3.0. Shouldn't it be possible to avoid rebuilding Subversion by installing serf-1.3 on top of serf-1.2? That's the point of shared libraries...
Re: Proxy error on SVN 1.8.1
Hi, On Wed, Jul 31, 2013 at 11:30 AM, Guillaume Lasnier guillaume.lasn...@hybris.com wrote: Hi Lieven, Please find attached the tcpdump that dumps traffic between my laptop and the proxy. The only information I could get about the proxy is that it's an ISA server. from the trace I don't really see what's going on, the proxy returns 200 Connection Established so the ssl tunnel was setup correctly, including proxy authentication. Now I see that homebrew provides serf 1.2.1, also for Subversion 1.8.1 (*). Serf 1.3.0 is available which includes many fixes for the ssl tunnel and authentication code. So I propose that you test with serf 1.3.0 first. You'll have to build svn and serf manually or wait for the homebrew project to update serf to 1.3.0. Note: your username and password can be extract from the trace you sent, I suggest you change them. Lieven (*) https://github.com/mxcl/homebrew/commits/master/Library/Formula/serf.rb Regards -- Guillaume Lasnier On 7/29/13 7:01 PM, Lieven Govaerts l...@apache.org wrote: Hi, On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier guillaume.lasn...@hybris.com wrote: Hi all, When issuing the following command, I get the following error: $ svn -v log svn: E120107: Unable to connect to a repository at URL 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform' svn: E120107: Error running context: The proxy server returned an error while setting up the SSL tunnel. That error indicates the proxy returned an error to the CONNECT request that svn uses to initiate the ssl tunnel. What proxy server do you use? KeepAlive off? Specific authentication? I think the easiest way to find out what's going on is to trace the network traffic. Can you make a trace with fiddler or wireshark? I am using subversion 1.8.1 on Mac OS X installed with homebrew. I have configured the proxy the following way in ~/.subversion/servers : [groups] # group1 = *.collab.net # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com mygroup = *.myhost.mydomain # Information for my group: [mygroup] http-proxy-host = 192.168.xxx.xxx http-proxy-port = 1234 http-proxy-username = john http-proxy-password = doe This configuration used to work with subversion 1.7. Configuration looks ok, and if it has worked before then we should be able to make it work in 1.8.1 too. Lieven Do have any idea? -- Guillaume Lasnier
Re: Proxy error on SVN 1.8.1
Hi Lieven, Please find attached the tcpdump that dumps traffic between my laptop and the proxy. The only information I could get about the proxy is that it's an ISA server. Regards -- Guillaume Lasnier On 7/29/13 7:01 PM, Lieven Govaerts l...@apache.org wrote: Hi, On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier guillaume.lasn...@hybris.com wrote: Hi all, When issuing the following command, I get the following error: $ svn -v log svn: E120107: Unable to connect to a repository at URL 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform' svn: E120107: Error running context: The proxy server returned an error while setting up the SSL tunnel. That error indicates the proxy returned an error to the CONNECT request that svn uses to initiate the ssl tunnel. What proxy server do you use? KeepAlive off? Specific authentication? I think the easiest way to find out what's going on is to trace the network traffic. Can you make a trace with fiddler or wireshark? I am using subversion 1.8.1 on Mac OS X installed with homebrew. I have configured the proxy the following way in ~/.subversion/servers : [groups] # group1 = *.collab.net # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com mygroup = *.myhost.mydomain # Information for my group: [mygroup] http-proxy-host = 192.168.xxx.xxx http-proxy-port = 1234 http-proxy-username = john http-proxy-password = doe This configuration used to work with subversion 1.7. Configuration looks ok, and if it has worked before then we should be able to make it work in 1.8.1 too. Lieven Do have any idea? -- Guillaume Lasnier tcpdump-filter.pcap Description: tcpdump-filter.pcap
Proxy error on SVN 1.8.1
Hi all, When issuing the following command, I get the following error: $ svn -v log svn: E120107: Unable to connect to a repository at URL 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform' svn: E120107: Error running context: The proxy server returned an error while setting up the SSL tunnel. I am using subversion 1.8.1 on Mac OS X installed with homebrew. I have configured the proxy the following way in ~/.subversion/servers : [groups] # group1 = *.collab.net # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com mygroup = *.myhost.mydomain # Information for my group: [mygroup] http-proxy-host = 192.168.xxx.xxx http-proxy-port = 1234 http-proxy-username = john http-proxy-password = doe This configuration used to work with subversion 1.7. Do have any idea? -- Guillaume Lasnier
Re: Proxy error on SVN 1.8.1
Hi, On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier guillaume.lasn...@hybris.com wrote: Hi all, When issuing the following command, I get the following error: $ svn -v log svn: E120107: Unable to connect to a repository at URL 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform' svn: E120107: Error running context: The proxy server returned an error while setting up the SSL tunnel. That error indicates the proxy returned an error to the CONNECT request that svn uses to initiate the ssl tunnel. What proxy server do you use? KeepAlive off? Specific authentication? I think the easiest way to find out what's going on is to trace the network traffic. Can you make a trace with fiddler or wireshark? I am using subversion 1.8.1 on Mac OS X installed with homebrew. I have configured the proxy the following way in ~/.subversion/servers : [groups] # group1 = *.collab.net # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com mygroup = *.myhost.mydomain # Information for my group: [mygroup] http-proxy-host = 192.168.xxx.xxx http-proxy-port = 1234 http-proxy-username = john http-proxy-password = doe This configuration used to work with subversion 1.7. Configuration looks ok, and if it has worked before then we should be able to make it work in 1.8.1 too. Lieven Do have any idea? -- Guillaume Lasnier
Re: Merge error with SVN 1.8.0
On Saturday, June 29, 2013 01:18:16 PM Stefan Sperling wrote: On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote: [copying dev@ because I found what the issue is] Hi, Did some further investigation and it turns out that SVN1.8 client creates more connections to the server when performing 'svn merge' - exceeding the xinetd's default number of connections per source (10) and indeed, closing the connection on an unsuspecting client. After increasing the number of connections per source to unlimited, the merge went through. Here are some statistics: SVN 1.7, merge --reintegrate 13 connections total, 5 concurrent connections maximum SVN 1.8, merge 18 connections total, 11 concurrent connections maximum SVN 1.8, merge --reintegrate 5 connections total, 3 concurrent connections maximum So, it looks like the new code for automatic detection of reintegration merges in 1.8 spawns a bunch of additional connections. So, the question is - what is the maximum number of connections that a client can create to a server? Does it depend on the size of the change? Size of the svn:mergeinfo? I am not comfortable leaving the server configuration at unlimited, seeing that xinetd limit is a safety net against runaway client bringing down the server. I'm not entirely sure how to estimate the largest number of connections made by 'svn merge'. Note that the number of connections also depends on the amount of svn:externals involved in checkouts and updates. One new connection is opened for each external. You might be interested in Ivan's RA session reuse patch: http://svn.haxx.se/dev/archive-2013-06/0292.shtml http://subversion.tigris.org/issues/show_bug.cgi?id=3763 This will probably be in 1.9, so it won't help you now. But I still thought it was worth mentioning since it will address your problem in the long term. Sorry for a late response. The checked out WC I did a merge in did not have any externals, but it had 8 svn:mergeinfo entries, if it matters. I think at the very least this issue needs to be reflected in the SVN book. Right now, the section svnserve via xinetd does not mention it, nor does the example configuration specify an unlimited number of connections per source. Given that xinentd's default is 10 connections per source IP, it is fairly easy to go over that limit. As to session reuse: am I right that it is going to avoid closing connections and reuse it instead of opening a new one? In that case, it does not solve an issue with concurrent connections (as they're still active, they can't be reused). Regards, Alexey.
Re: Merge error with SVN 1.8.0
On Sunday, June 30, 2013 04:33:45 PM Branko Čibej wrote: On 24.06.2013 01:38, Alexey Neyman wrote: Are you calling RPMs provided by WanDisco's fun and games? I think Subversion developers employed by WanDisco might be somewhat insulted by such judgment. Hmm I'd sooner be insulted by someone anticipating my reaction like that. :) Nobody's perfect. If you find a bug in WANdisco's binary packages, I for one would definitely like to know about it. Sorry for insulting you then :) My point was that the problem is most likely not a *packaging* issue, which was confirmed in my next message (the issue is due to 1.8.x making more connections from client to server when doing 'svn merge'). Regards, Alexey.
Re: Merge error with SVN 1.8.0
On 05.07.2013 23:04, Alexey Neyman wrote: My point was that the problem is most likely not a *packaging* issue, which was confirmed in my next message (the issue is due to 1.8.x making more connections from client to server when doing 'svn merge'). That's most likely a side effect of the improved merge behaviour, and something we probably want to fix in a future release. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Merge error with SVN 1.8.0
On Sun, Jun 23, 2013 at 7:38 PM, Alexey Neyman sti...@att.net wrote: On Sunday, June 23, 2013 07:20:50 PM Nico Kadel-Garcia wrote: On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman sti...@att.net wrote: Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying around and confusing you? Or binaries turning up in your commit scripts due to inherited PATH that does not include the new version? Sorry for being unclear: I only upgraded the CLIENT, not the server. The server still has 1.6.11. And yes, sorry for stating the obvious, the 1.7.10 subversion RPM was removed when I installed 1.8.0. To avoid the fun and games, I urge you to grab and test my newly minted Subversion 1.8.0 RPM building tools, at: https://github.com/nkadel/subversion-1.8.x-srpm Are you calling RPMs provided by WanDisco's fun and games? I think Subversion developers employed by WanDisco might be somewhat insulted by such judgment. Is there something wrong with RPMs from WanDisco that I must, in your opinion, switch to your version? No, no, I missed that you were using WanDisco RPM's. (Not sure how I missed that, I do sometimes get interrupted doing my email.) I respect WanDisco's work and had no intent to insult them. And if you're using WanDisco, I'd seriously consider a commercial contract with them to take advantage of their multiple-master tools for mirroring Subversion repositories safely. That would actually help *fund* Subversion development. In fact If you can, I'd consider making a copy of the repository to another host and testing it with the Wandisco or another Subversion 1.8.0 *server*, not just client. I've also bundled a libserf SRPM building toolkit at: https://github.com/nkadel/libserf-1.2.x-srpm Thanks. I thought that my original email indicated that we're using svn:// protocol and thus serf is out of the equation. It's cool. I'm not suggesting you have to locally build or compile serf unless you care to build from my SRPM, It's a dependency for building a full Subversion 1.8.0 toolkit. If you feel like getting into the code yourself, you'll need something like it. In fact.. If you like playing with source and working with your own copies, In other words: do you have anything relevant to say regarding the reported issue, rather than advertising your work? I made a mistake about the source of your software, and did apologize. Since it's from Wandisco, and you're jumping to the bleeding edge with Subvesion 1.8.x on RHEL 6 based operating systems, why not contact them for commercial support?
Re: Merge error with SVN 1.8.0
On 24.06.2013 01:38, Alexey Neyman wrote: Are you calling RPMs provided by WanDisco's fun and games? I think Subversion developers employed by WanDisco might be somewhat insulted by such judgment. Hmm I'd sooner be insulted by someone anticipating my reaction like that. :) Nobody's perfect. If you find a bug in WANdisco's binary packages, I for one would definitely like to know about it. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Merge error with SVN 1.8.0
On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote: [copying dev@ because I found what the issue is] Hi, Did some further investigation and it turns out that SVN1.8 client creates more connections to the server when performing 'svn merge' - exceeding the xinetd's default number of connections per source (10) and indeed, closing the connection on an unsuspecting client. After increasing the number of connections per source to unlimited, the merge went through. Here are some statistics: SVN 1.7, merge --reintegrate 13 connections total, 5 concurrent connections maximum SVN 1.8, merge 18 connections total, 11 concurrent connections maximum SVN 1.8, merge --reintegrate 5 connections total, 3 concurrent connections maximum So, it looks like the new code for automatic detection of reintegration merges in 1.8 spawns a bunch of additional connections. So, the question is - what is the maximum number of connections that a client can create to a server? Does it depend on the size of the change? Size of the svn:mergeinfo? I am not comfortable leaving the server configuration at unlimited, seeing that xinetd limit is a safety net against runaway client bringing down the server. I'm not entirely sure how to estimate the largest number of connections made by 'svn merge'. Note that the number of connections also depends on the amount of svn:externals involved in checkouts and updates. One new connection is opened for each external. You might be interested in Ivan's RA session reuse patch: http://svn.haxx.se/dev/archive-2013-06/0292.shtml http://subversion.tigris.org/issues/show_bug.cgi?id=3763 This will probably be in 1.9, so it won't help you now. But I still thought it was worth mentioning since it will address your problem in the long term.
Merge error with SVN 1.8.0
Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
Re: Merge error with SVN 1.8.0
On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman sti...@att.net wrote: Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying around and confusing you? Or binaries turning up in your commit scripts due to inherited PATH that does not include the new version? To avoid the fun and games, I urge you to grab and test my newly minted Subversion 1.8.0 RPM building tools, at: https://github.com/nkadel/subversion-1.8.x-srpm I've also bundled a libserf SRPM building toolkit at: https://github.com/nkadel/libserf-1.2.x-srpm I've been testing out the 1.8.x features, it's suitable for pushing to Rpmforge. EPEL would take a lot more work because there are key libraries, like SQLite, that have to be compiled locally even for RHEL 6. And Fedora 19, which is coming out, does not use SysV init scripts at all, it uses system, so the svnserve init script will be rejected out of hand. http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
Re: Merge error with SVN 1.8.0
On Sunday, June 23, 2013 07:20:50 PM Nico Kadel-Garcia wrote: On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman sti...@att.net wrote: Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying around and confusing you? Or binaries turning up in your commit scripts due to inherited PATH that does not include the new version? Sorry for being unclear: I only upgraded the CLIENT, not the server. The server still has 1.6.11. And yes, sorry for stating the obvious, the 1.7.10 subversion RPM was removed when I installed 1.8.0. To avoid the fun and games, I urge you to grab and test my newly minted Subversion 1.8.0 RPM building tools, at: https://github.com/nkadel/subversion-1.8.x-srpm Are you calling RPMs provided by WanDisco's fun and games? I think Subversion developers employed by WanDisco might be somewhat insulted by such judgment. Is there something wrong with RPMs from WanDisco that I must, in your opinion, switch to your version? I've also bundled a libserf SRPM building toolkit at: https://github.com/nkadel/libserf-1.2.x-srpm Thanks. I thought that my original email indicated that we're using svn:// protocol and thus serf is out of the equation. In other words: do you have anything relevant to say regarding the reported issue, rather than advertising your work? Regards, Alexey. I've been testing out the 1.8.x features, it's suitable for pushing to Rpmforge. EPEL would take a lot more work because there are key libraries, like SQLite, that have to be compiled locally even for RHEL 6. And Fedora 19, which is coming out, does not use SysV init scripts at all, it uses system, so the svnserve init script will be rejected out of hand. http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
error on SVN upgrade working copy when repository has been relocated
The error message has been reported previously, but I did not see that the problem has been resolved: (I had to type by hand as cp did not work) --- Subversion Exception! --- (snip) 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.7.6\ext\subversion\subversion\libsvn_wc\util.c' line 300: assertion failed (svn_uri_is_canonical(repos_url, pool) svn_relpath_is_canonical(path_in_repos) SVN_IS_VALID_REVNUM(peg_rev)) What I was doing: I did SVN upgrade working copy from version 1.6 to 1.7. Since my last update the svn repository has been relocated to a new url. (I haven't used the rep on this computer for quite some time.) Could that be the cause? I could reproduce the error with a different folder of the same rep, so it was also relocated. Immediately before, I have upgraded a different working copy of a different folder without error. The rep is the same (so it has also moved), but it might be that I had already relocated the rep with a 1.6-subversion (sorry that I do not remember for sure). OS: Windows 7 Home Premium Suversion id: TortoiseSVN 1.7.6, Build 22632 - 64 Bit , 2012/03/08 18:29:39 Subversion 1.7.4, apr 1.4.5 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0g 18 Jan 2012 zlib 1.2.5
RE: error on SVN upgrade working copy when repository has been relocated
-Original Message- From: Johannes Lengler [mailto:johannes.leng...@googlemail.com] Sent: vrijdag 27 juli 2012 10:52 To: users@subversion.apache.org Subject: error on SVN upgrade working copy when repository has been relocated The error message has been reported previously, but I did not see that the problem has been resolved: (I had to type by hand as cp did not work) This assertion is caused by a tree conflict containing a url that is not normalized properly according to the 1.7 rules. This issue has been fixed on trunk and the fix will be part of Subversion 1.7.6. (The fix is of course that we normalize this url on import) If possible I would recommend marking the tree conflict as resolved using an old client and then upgrading again. Bert
Re: Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
1.7.5 will include this fix. Current plan is to announce it as GA on Thursday. From CHANGES: - Server-side bugfixes: * mod_dav_svn: support compiling/running under httpd-2.4 (r1232267) * mod_dav_svn: forbid BDB repositories under httpd's event MPM (issue #4157) Michael Ben-David wrote on Mon, May 14, 2012 at 12:45:45 -0700: +1 for this. I just ran into it with: --without-berkeley-db On Friday, 20 April 2012 02:21:05 UTC-4, Daniel Shahaf wrote: We're working in this (mostly Philip). It's possible that 1.7.5 will allow compiling and running against httpd-2.4, so long as the 'event' MPM and BDB-backed repositories aren't used at the same time (see issue #4157). The underlying problem of making bdb/event act nicely is outstanding Ralph Seichter wrote on Thu, Apr 19, 2012 at 12:40:39 +0200: Hi list, in February, Mario Brandt started a thread about a compile error against Apache 2.4.x (see http://svn.haxx.se/dev/archive-2012-02/0486.shtml). subversion/mod_dav_svn/util.c: In function 'dav_svn__log_err': subversion/mod_dav_svn/util.c:630:20: error: 'dav_error' has no member named 'save_errno' subversion/mod_dav_svn/util.c:631:28: error: 'dav_error' has no member named 'save_errno' A patch was suggested and discussed with Daniel Shahaf. As far as I can tell from the mailing list archives, no release date has been named for the fix, or have I overlooked something? -Ralph
Re: Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
On 15.05.12 09:56, Daniel Shahaf wrote: 1.7.5 will include this fix. That's good news, thanks. -Ralph
Re: Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
+1 for this. I just ran into it with: --without-berkeley-db On Friday, 20 April 2012 02:21:05 UTC-4, Daniel Shahaf wrote: We're working in this (mostly Philip). It's possible that 1.7.5 will allow compiling and running against httpd-2.4, so long as the 'event' MPM and BDB-backed repositories aren't used at the same time (see issue #4157). The underlying problem of making bdb/event act nicely is outstanding Ralph Seichter wrote on Thu, Apr 19, 2012 at 12:40:39 +0200: Hi list, in February, Mario Brandt started a thread about a compile error against Apache 2.4.x (see http://svn.haxx.se/dev/archive-2012-02/0486.shtml). subversion/mod_dav_svn/util.c: In function 'dav_svn__log_err': subversion/mod_dav_svn/util.c:630:20: error: 'dav_error' has no member named 'save_errno' subversion/mod_dav_svn/util.c:631:28: error: 'dav_error' has no member named 'save_errno' A patch was suggested and discussed with Daniel Shahaf. As far as I can tell from the mailing list archives, no release date has been named for the fix, or have I overlooked something? -Ralph
Re: Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
We're working in this (mostly Philip). It's possible that 1.7.5 will allow compiling and running against httpd-2.4, so long as the 'event' MPM and BDB-backed repositories aren't used at the same time (see issue #4157). The underlying problem of making bdb/event act nicely is outstanding Ralph Seichter wrote on Thu, Apr 19, 2012 at 12:40:39 +0200: Hi list, in February, Mario Brandt started a thread about a compile error against Apache 2.4.x (see http://svn.haxx.se/dev/archive-2012-02/0486.shtml). subversion/mod_dav_svn/util.c: In function 'dav_svn__log_err': subversion/mod_dav_svn/util.c:630:20: error: 'dav_error' has no member named 'save_errno' subversion/mod_dav_svn/util.c:631:28: error: 'dav_error' has no member named 'save_errno' A patch was suggested and discussed with Daniel Shahaf. As far as I can tell from the mailing list archives, no release date has been named for the fix, or have I overlooked something? -Ralph
Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
Hi list, in February, Mario Brandt started a thread about a compile error against Apache 2.4.x (see http://svn.haxx.se/dev/archive-2012-02/0486.shtml). subversion/mod_dav_svn/util.c: In function 'dav_svn__log_err': subversion/mod_dav_svn/util.c:630:20: error: 'dav_error' has no member named 'save_errno' subversion/mod_dav_svn/util.c:631:28: error: 'dav_error' has no member named 'save_errno' A patch was suggested and discussed with Daniel Shahaf. As far as I can tell from the mailing list archives, no release date has been named for the fix, or have I overlooked something? -Ralph
Re: Error with svn diff
On Apr 27, 2011, at 20:06, Tony Butt wrote: On Wed, 2011-04-27 at 02:05 -0500, Ryan Schmidt wrote: Do educate on which files should have svn:eol-style set to what value, and do encourage developers to use auto-props to automate what they learned, but also install a pre-commit hook script in the repository that absolutely prevents the problem from happening in the future. If you've decided for example that .txt files shall have the svn:eol-style set to native, then write and install a pre-commit hook script that prevents anyone from adding any .txt file that does not have svn:eol-style set to native. Do you know offhand of a similar script to require particular properties? It seems that there should be a generic pre-commit script that would prevent any commit that doesn't match the properties specified in the autoprops section of a given config file. But I don't know where that script might be.
Re: Error with svn diff
On Apr 26, 2011, at 18:46, Tony Butt wrote: On Fri, 2011-04-15 at 02:31 -0500, Ryan Schmidt wrote: Is it possible the document has mixed line ending styles? -- some lines ending with CRLF and some ending with LF? If so, fix this, ideally by making use of the svn:eol-style property. It is probable the document has mixed line style endings - I have updated the line endings in a test repository, but that does not help with a historical diff. If you can afford to take the repository offline for awhile, and force everybody to check out new working copies, you can fix your historical line endings by using svndumptool's eolfix option. http://svn.borg.ch/svndumptool/ In the meantime, I am trying to educate the engineers involved about the merits of auto-props, so this is less likely to happen in the future. Do educate on which files should have svn:eol-style set to what value, and do encourage developers to use auto-props to automate what they learned, but also install a pre-commit hook script in the repository that absolutely prevents the problem from happening in the future. If you've decided for example that .txt files shall have the svn:eol-style set to native, then write and install a pre-commit hook script that prevents anyone from adding any .txt file that does not have svn:eol-style set to native.
Re: Error with svn diff
On Wed, 2011-04-27 at 02:05 -0500, Ryan Schmidt wrote: On Apr 26, 2011, at 18:46, Tony Butt wrote: On Fri, 2011-04-15 at 02:31 -0500, Ryan Schmidt wrote: Is it possible the document has mixed line ending styles? -- some lines ending with CRLF and some ending with LF? If so, fix this, ideally by making use of the svn:eol-style property. It is probable the document has mixed line style endings - I have updated the line endings in a test repository, but that does not help with a historical diff. If you can afford to take the repository offline for awhile, and force everybody to check out new working copies, you can fix your historical line endings by using svndumptool's eolfix option. http://svn.borg.ch/svndumptool/ Unfortunately not practical, unless I work overnight. From past experience with our repo, that takes several hours. For me, using an external diff (gnu diff) with the offending package (codestriker) works fine in this case. In the meantime, I am trying to educate the engineers involved about the merits of auto-props, so this is less likely to happen in the future. Do educate on which files should have svn:eol-style set to what value, and do encourage developers to use auto-props to automate what they learned, but also install a pre-commit hook script in the repository that absolutely prevents the problem from happening in the future. If you've decided for example that .txt files shall have the svn:eol-style set to native, then write and install a pre-commit hook script that prevents anyone from adding any .txt file that does not have svn:eol-style set to native. Do you know offhand of a similar script to require particular properties? -- Tony Butt tony.b...@cea.com.au CEA Technologies
Re: Error with svn diff
Tony Butt wrote on Thu, Apr 28, 2011 at 11:06:36 +1000: For me, using an external diff (gnu diff) with the offending package (codestriker) works fine in this case. The internal diff has an option to ignore line endings. (and, at least in trunk (don't know about 1.6), you can set that option in your ~/.subversion/config file too)
Re: Error with svn diff
On Fri, 2011-04-15 at 02:31 -0500, Ryan Schmidt wrote: On Apr 15, 2011, at 01:06, Tony Butt wrote: On a particular piece of code, the svn diff header claims 33 old lines, when there are actually 32. I have re-run this with an external diff command (svn diff -r 57968:57969 --old somepath --diff-cmd=/usr/bin/diff out.diff) and the problem goes away. You're talking about the header that looks like this? @@ -183,6 +185,8 @@ (Meaning, in this case: The old version had 6 lines beginning at line 183; the new version has 8 lines beginning at line 185) Is it possible the document has mixed line ending styles? -- some lines ending with CRLF and some ending with LF? If so, fix this, ideally by making use of the svn:eol-style property. It is probable the document has mixed line style endings - I have updated the line endings in a test repository, but that does not help with a historical diff. In the meantime, I am trying to educate the engineers involved about the merits of auto-props, so this is less likely to happen in the future. Thanks, Tony -- Tony Butt tony.b...@cea.com.au CEA Technologies
Error with svn diff
We are using Subversion 1.6.16 on a Ubuntu Lucid box, and a Ubuntu Hardy (8.04) box hosting a subversion 1.6.16 repository via apache. We use this configuration to support codestriker 1.9.10 for code reviews, and have recently hit a problem with some of our reviews. After carefully stepping through the codestriker code with some of our affected source code, I found a problem with svn diff The codestriker code checks the summary of lines changed at the top of each diff block against the actual lines in the block, and rejects the diff as malformed if they do not match. On a particular piece of code, the svn diff header claims 33 old lines, when there are actually 32. I have re-run this with an external diff command (svn diff -r 57968:57969 --old somepath --diff-cmd=/usr/bin/diff out.diff) and the problem goes away. I reverted my subversion installation to 1.6.6, and the problem is still present. I am loathe to post the diff, as the project is somewhat sensitive - we build systems for defence here. Finally, I am away on leave for a week, so cannot reply until after 26th April. -- Tony Butt tony.b...@cea.com.au CEA Technologies
Re: Error with svn diff
On Apr 15, 2011, at 01:06, Tony Butt wrote: On a particular piece of code, the svn diff header claims 33 old lines, when there are actually 32. I have re-run this with an external diff command (svn diff -r 57968:57969 --old somepath --diff-cmd=/usr/bin/diff out.diff) and the problem goes away. You're talking about the header that looks like this? @@ -183,6 +185,8 @@ (Meaning, in this case: The old version had 6 lines beginning at line 183; the new version has 8 lines beginning at line 185) Is it possible the document has mixed line ending styles? -- some lines ending with CRLF and some ending with LF? If so, fix this, ideally by making use of the svn:eol-style property.
