Re: upgrade to subversion 1.8.5 suspected bug
Remember to Reply All so this conversation stays on the public mailing list instead of in private email. On Jan 8, 2014, at 20:11, Austin Mico wrote: On Thu, Jan 9, 2014 at 1:13 AM, Ryan Schmidt wrote: On Jan 8, 2014, at 04:40, Austin Mico wrote: I have tried to upgrade with the latest version 1.8.5 but found to have the display of the repository with apache to be incorrect wherein php codes were displayed incorrectly. Some of the codes were truncated. Please be more specific. The repository is being served by apache through mod_dav_svn. The php source code can be checkout correctly but when you view it on with internet browser the codes were truncated. There are missing codes and there seems to be no new line character. I mean: give me an exact set of commands I can use to reproduce this problem on my system. If this is a public repository, give me the URL I should look at. If it’s a private repository that you cannot give access to, give a set of steps to create from scratch a repository that demonstrates the problem.
SVN Tool Qualification ISO 26262
Dear SVN users, does anybody of you have experience using SVN for developing safety-critical software? We are currently involved in a software development project for automotive industry where SVN is used in the development tool chain. Safety standards like ISO 26262 require a proof that software tools like SVN do not introduce errors into the final product. Tool vendors for commercial tools usually provide support for tool qualification, e.g. by reference work flows. For SVN being an open source tool we could not find any practises for tool qualification of SVN so far. If you have faced similar challenges in your project, we would appreciate your feedback. Thanks. Joachim
How to change the svn password by the user?
Hi, I am from PTC Software, Pune. I wanted a normal user(not admin) to change his credentials in SVN. Can you please help with this? Thanks, -Narayana Reddy.
Error upgrading repository
Hello, I get the following error when I want to upgrade the repository on the server. E:\Subversionsvnadmin upgrade e:\Subversion\Postbote Repository lock acquired. Please wait; upgrading the repository may take some time... This application has halted due to an unexpected error. A crash report and minidump file were saved to disk, you can find them here: C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\svn-crash-log20140109130442.log C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\svn-crash-log20140109130442.dmp Please send the log file to users@subversion.apache.org to help us analyze and solve this problem. NOTE: The crash report and minidump files can contain some sensitive information (filenames, partial file content, usernames and passwords etc.) The files are attached. It would be nice if someone could tell me whats wrong and what to do to make it work Thanks. regards M.Koetz Hard- und Software Consulting GmbH Obstland-Straße 48, OT Dürrweitzschen 04668 Grimma Telefon: 034386 5020 Telefax: 034386 50299 Hotline HSC Lohn : 034386 50260 Hotline Finanz Plus: 034386 50261 Hotline Auftrag Plus: 034386 50262 Geschäftsführer: Dr. Peter Kötz Amtsgericht Leipzig HRB-Nr. 96 Wir haben Software-Schulungen in Dürrweitzschen, Bautzen, Ollendorf und Berlin für Sie geplant. svn-crash-log20140109131532.dmp Description: Binary data svn-crash-log20140109131532.log Description: Binary data
Re: Error upgrading repository
On Thu, Jan 9, 2014 at 1:27 PM, Michael Koetz michael.ko...@hsc-software.de wrote: Hello, I get the following error when I want to upgrade the repository on the server. E:\Subversionsvnadmin upgrade e:\Subversion\Postbote Repository lock acquired. Please wait; upgrading the repository may take some time... This application has halted due to an unexpected error. A crash report and minidump file were saved to disk, you can find them here: C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\svn-crash-log20140109130442.log C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\svn-crash-log20140109130442.dmp Please send the log file to users@subversion.apache.org to help us analyze and solve this problem. NOTE: The crash report and minidump files can contain some sensitive information (filenames, partial file content, usernames and passwords etc.) The files are attached. It would be nice if someone could tell me whats wrong and what to do to make it work This bug was fixed in svn 1.8.1 [1] (you're using 1.8.0). I suggest you grab the latest release (1.8.5 at the moment). [1] http://svn.apache.org/viewvc?view=revisionrevision=r1494287 -- Johan
Re: Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
On Wed, Jan 8, 2014 at 4:53 PM, Philip Martin wrote: I get a problem with the checkout from your server using a trunk client. Very occasionally the checkout works but most of the time the client simply hangs while receiving the first file. It appears that the client is sending the REPORT request and receiving the response from the server. The client then pipelines 13 GET requests corresponding to the 13 files in the working copy. The server starts sending the response to the first GET and the client starts receiving it but the server never completes the response. The client hangs waiting for the server and eventually times out. If I use wireshark it shows the server sending an RST packet just before the client hangs. According to wireshark this is a Bad checksum packet. Wireshark shows the client retransmitting the GETs but there is no further server repsonse. I don't know enough to debug the problem further. I now upgraded the SVN client to 1.9.0-dev from trunk. With trunk version it's still inconsistent behaviour, but at least reproducible to a certain extent. I tried to checkout file a couple of times. Almost every time I get the following lines in error.log on the server: Unable to deliver content. [500, #0] Could not write data to filter. [500, #175002] but the first time the whole checkout finished successfully, even though the server first recorded 500 and apparently another 200 (success) on the second attempt for the same file. The client ended with success. The second time the client reported svn: E54: Error running context: Connection reset by peer (and the same happened when I ran it for the third/fourth/fifth/... time) Sometimes it works though. And it usually hangs on different files. I'm unable to reproduce the faulty behaviour if I do a checkout from the same network where the server is located, no matter what I try (upgrading SVN client doesn't help triggering the error). Philip also said that he had no problem doing a checkout with client version 1.8.5 or 1.7. With subversion client 1.8.5 I'm sometimes able to reproduce the problem from a different network, but it usually works. I tried wireshark, but I don't know what to do with the zillions of packets it shows me. I'll first try to copy the repository to another server to see if I could reproduce the problem from there. Other than that I would be grateful for any hints if there exists some painless way to debug the server. Mojca
RE: How to change the svn password by the user?
Hi, I am from PTC Software, Pune. I wanted a normal user(not admin) to change his credentials in SVN. Can you please help with this? Thanks, -Narayana Reddy. I would suggest using Subversion Edge by Collabnet. It is free, and bundles svn, apache and a web based management tool. Users can log into the web portal and change their passwords. I'm not sure if there is a way to force password changes... for that I suggest using windows domain accounts or some NTLM server. BOb
Re: Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
On 09.01.2014 17:09, Mojca Miklavec wrote: I'm unable to reproduce the faulty behaviour if I do a checkout from the same network where the server is located, no matter what I try (upgrading SVN client doesn't help triggering the error). Philip also said that he had no problem doing a checkout with client version 1.8.5 or 1.7. This confirms my suspicion that the error is triggered by some part of the network infrastructure between your server and the outside world. That's why I asked if there is a load-balancer involved. It could also be caused by some kind of transparent proxy, or even a packet analyzer. I doubt that your server is open to the world without some kind of security measures in place. To be clear, I'm not saying that any of these things are configured incorrectly; only that they may be interacting with Subversion in a way that we don't handle well. One of the major differences between 1.7 (which works) and 1.8 (which fails) is that we try to work around issues with non-standard behaviour of certain transparent (sic) proxies; and we can't claim to have covered all the possibilities. I can't see a way to figure out what's going on without help from your network admins; we need some insight into why the connection is being reset on the server side, and analyzing the TCP stream on the client can't tell us that. BTW, if you think it'd help to try a live debugging session, I'm only about an hour's drive away from IJS. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
On 1/9/14, 11:19 AM, Branko Čibej wrote: To be clear, I'm not saying that any of these things are configured incorrectly; only that they may be interacting with Subversion in a way that we don't handle well. One of the major differences between 1.7 (which works) and 1.8 (which fails) is that we try to work around issues with non-standard behaviour of certain transparent (sic) proxies; and we can't claim to have covered all the possibilities. Actually we know we haven't covered all possibilities. Had someone a while back that had mod_security setup in such a way that it was rejecting some request methods (think it was POST) without Content-Length (thus breaking chunked requests). The behavior didn't fail for the OPTION requests so our probe to try and work around transparent proxies failed. But I'm not sure what this thread would really have to do with chunked requests, since the problem seems to be pipelining which as far as I know we don't have any workarounds for. We can rule out the chunked requests by disabling it by adding this to the command line --config-option servers:global:http-chunked-requests=no and seeing if it changes anything. But I really doubt it based on what I've seen on this thread. More details on what Branko is talking about and the config option I mentioned here: https://subversion.apache.org/docs/release-notes/1.8.html#411-length-required
Receiving an error via an SVN repository
Hello, We are running Tortoise SVN on a Windows 7 machine - and had some network issues were connectivity to our share where the repository was stored was up and down. We've had the user copy the files locally and they can access them and commit them but when trying to recommit them to the network repository they were getting a file lock error. The user was able to break the lock but now receives this error : Error: Can't set position pointer [...] : An attempt was made to move the file pointer before the beginning of the file and can't reconnect to the SVN repository on the network. I see this link to http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html to unwedge a repository but wanted to check to see if you had any recommendations on what to do before trying to do a restore of the repository or should we try the unwedge action first? Thanks much in advance for your assistance. Ronda Sinclair
Re: Receiving an error via an SVN repository
On 1/9/14, 2:11 PM, Sinclair, Ronda D. wrote: We are running Tortoise SVN on a Windows 7 machine – and had some network issues were connectivity to our share where the repository was stored was up and down. We’ve had the user copy the files locally and they can access them and commit them but when trying to recommit them to the network repository they were getting a file lock error. The user was able to break the lock but now receives this error : Error: Can't set position pointer [...] : An attempt was made to move the file pointer before the beginning of the file and can’t reconnect to the SVN repository on the network. Hard to make much of that. Can you post the full and exact error message (you can ommit paths just don't ommit error codes and exact phrasing of the error messages)? Also it would probably be helpful to provide an exact version of Subversion that you're using. The one concern I do have is it sounds like you were putting the repo on a network file share and then using ra_local (file:///) to access it. I wouldn't recommend that. If you want to allow network access to the repository I'd suggest using one of our server processes. I see this link to http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html to unwedge a repository but wanted to check to see if you had any recommendations on what to do before trying to do a restore of the repository or should we try the “unwedge” action first? FSFS repos don't get wedged, is this a BDB repo? Biggest suggestion I can make is make sure you are working off a copy of the repo and not your only copy.
svnadmin verify 1.8.5 errors on old repositories
I've observed 3 instances of similar errors when using the 1.8.5 svnadmin verify on 3 different old repositories. (the hundreds of other repos on this server verified in 1.8.5 without problems.) svnadmin: E160004: r97's root node's predecessor is r90 but should be r96 svnadmin: E160004: r502's root node's predecessor is r483 but should be r501 svnadmin: E160004: r22033's root node's predecessor is r22031 but should be r22032 All 3 of these repositories verify without errors using 1.7.5. All 3 of the revisions are from different months in 2009, when I assume the server was running 1.6.something. The repositories were upgraded, but not a full dump/load between major version upgrades. svn 1.8.5 can serve the existing repositories without any observed errors. I can use a 1.8.5 svnsync to a new repository which then verifies without errors. Is this just a case of svnadmin verify in 1.8.5 being too conservative and should be issuing a warning instead? All 3 repositories are quite large (over 200GB each) and have the same fsfs format: cat format 5 cat db/format 4 layout linear Obviously I could fix the error by doing a full dump/load cycle, but I'm interested in figuring out more about the cause. I can't provide the repo due to size and content, but I'm happy to dig around some of the files for more information. Also, on a slightly related note, why does the new svnadmin verify medatadata portion not always start at r0 or even show consecutive revision numbers on repositories with large numbers of revisions? Thanks! Kevin
Re: svnadmin verify 1.8.5 errors on old repositories
On 1/9/14, 2:48 PM, kmra...@rockwellcollins.com wrote: I've observed 3 instances of similar errors when using the 1.8.5 svnadmin verify on 3 different old repositories. (the hundreds of other repos on this server verified in 1.8.5 without problems.) svnadmin: E160004: r97's root node's predecessor is r90 but should be r96 svnadmin: E160004: r502's root node's predecessor is r483 but should be r501 svnadmin: E160004: r22033's root node's predecessor is r22031 but should be r22032 All 3 of these repositories verify without errors using 1.7.5. All 3 of the revisions are from different months in 2009, when I assume the server was running 1.6.something. The repositories were upgraded, but not a full dump/load between major version upgrades. This is documented in the 1.8. release notes here: https://subversion.apache.org/docs/release-notes/1.8.html#verify-issue4129 Also, on a slightly related note, why does the new svnadmin verify medatadata portion not always start at r0 or even show consecutive revision numbers on repositories with large numbers of revisions? That's verifying the representation cache db. r0 will never have any entry since r0 is always an empty revision with no file contents (and thus no represenations). It will never have an entry for every revision. There are a couple reasons why a given revision might not have an entry: * rep-cache wasn't enabled when a revision was committed (most notably upgrade repos that existed before 1.6 when this feature was added and that haven't gone through a dump/load cycle since). * revision didn't add any new representations when it was committed. Copies with history (e.g. branching/tags) will use the representation from the source for the files. If a representation has already existed for a given file content and is found in the rep-cache.db then that representation will be reused for the file contents in the new revision.
Re: Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
Ben Reser b...@reser.org writes: Actually we know we haven't covered all possibilities. Had someone a while back that had mod_security setup in such a way that it was rejecting some request methods (think it was POST) without Content-Length (thus breaking chunked requests). The behavior didn't fail for the OPTION requests so our probe to try and work around transparent proxies failed. But I'm not sure what this thread would really have to do with chunked requests, since the problem seems to be pipelining which as far as I know we don't have any workarounds for. We can rule out the chunked requests by disabling it by adding this to the command line --config-option servers:global:http-chunked-requests=no and seeing if it changes anything. But I really doubt it based on what I've seen on this thread. Disabling chunked requests makes no difference. I see a trunk client failing most of the time, but occasionally it succeeds. When it fails it ususally hangs and eventually times-out, but occasionally it fails with Connection reset by peer. 1.8 fails like trunk, but 1.7/serf works. If we believe Wireshark then the server is sending an RST part way through the response to the first of 13 pipelined GETs. The response reponse is not chunked, it has Content-Length:8407648, but the client only receives 14480 bytes (I think that includes the headers). 1.7/serf, which works, pipelines 13 PROPFINDs as well as 13 GETs. If I force trunk to pipeline the PROPFINDs using: Index: ../src/subversion/libsvn_ra_serf/update.c === --- ../src/subversion/libsvn_ra_serf/update.c (revision 1557003) +++ ../src/subversion/libsvn_ra_serf/update.c (working copy) @@ -1630,7 +1630,7 @@ val = svn_xml_get_attr_value(inline-props, attrs); if (val (strcmp(val, true) == 0)) -ctx-add_props_included = TRUE; +ctx-add_props_included = FALSE; val = svn_xml_get_attr_value(send-all, attrs); if (val (strcmp(val, true) == 0)) @@ -1638,7 +1638,7 @@ ctx-send_all_mode = TRUE; /* All properties are included in send-all mode. */ - ctx-add_props_included = TRUE; + ctx-add_props_included = FALSE; } } else if (state == NONE strcmp(name.name, target-revision) == 0) then the checkout with trunk starts working reliably. Wireshark no longer shows an RST from the server, it does however show some packets marked TCP Previous segment not captured and some marked TCP Dup ACK. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: How to change the svn password by the user?
Thanks for your suggestion. I will try with this and get you back.. -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: 09 January 2014 21:52 To: Singareddy, Narayana Reddy; users@subversion.apache.org Subject: RE: How to change the svn password by the user? Hi, I am from PTC Software, Pune. I wanted a normal user(not admin) to change his credentials in SVN. Can you please help with this? Thanks, -Narayana Reddy. I would suggest using Subversion Edge by Collabnet. It is free, and bundles svn, apache and a web based management tool. Users can log into the web portal and change their passwords. I'm not sure if there is a way to force password changes... for that I suggest using windows domain accounts or some NTLM server. BOb
