Re: Slow VM, svn client drops connection with FIN packet
On 17.12.2013 16:19, Stuart MacDonald wrote: > On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote: > > So your server is using an nginx proxy, and your 1.7 client > doesn't work with it. The thing to do is to try to reproduce this > with 1.8, and if it's reproducible, it's still most likely a proxy > bug (nginx 1.0.5 is rather old). Reporting this to the server > administrator would be the next step. > > > The Wireshark trace shows clearly and conclusively this is a bug in > the client. The client drops the connection by sending a FIN packet > unexpectedly. It could be waiting for a response from the proxy that never reaches the client, and dropping the connection after a timeout. Regardless, you should still try to reproduce this with the latest client (ideally, both latest 1.7 and 1.8) to determine if the problem has been fixed. Especially in 1.8, there have been a lot of improvements in the HTTP protocol driver. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 16, 2013 at 12:45 PM, Mark Phippard wrote: > On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald < > stuartm.cod...@gmail.com> wrote: > >> If someone can point me at a Ubuntu-compatible package, I'm more than >> happy to upgrade. Last time I looked (within the last two months) I was >> unable to find anything later than what I'm running. I'd rather not spend >> the time compiling from source if I can avoid it. >> > > http://subversion.apache.org/packages.html#ubuntu > Yeah. The Ubuntu packages don't have either 1.7.14 or 1.8.5. The WANdisco packages require registration. What I said stands, there are no current Ubuntu-compatible packages. So, compiling from sources. ...Stu
Re: Slow VM, svn client drops connection with FIN packet
On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote: > > So your server is using an nginx proxy, and your 1.7 client doesn't work > with it. The thing to do is to try to reproduce this with 1.8, and if it's > reproducible, it's still most likely a proxy bug (nginx 1.0.5 is rather > old). Reporting this to the server administrator would be the next step. > The Wireshark trace shows clearly and conclusively this is a bug in the client. The client drops the connection by sending a FIN packet unexpectedly. ...Stu
"svn log --limit" very slow with 1.8 client and 1.4 server
https://subversion.apache.org/reporting-issues.html directed me to report issues to this mailing list. With svn 1.8.x (tested 1.8.3 and 1.8.5), "svn log" is very slow against older svnserve (tested 1.4.6) when specifying any path other than the root of the repository. eg. $ time svn log -l1 svn://host/repo > /dev/null real 0m0.039s user 0m0.008s sys 0m0.011s $ time svn log -l1 svn://host/repo/trunk > /dev/null real 5m55.153s user 0m0.670s sys 0m0.197s This is a repository with about 35k revisions. From a glance at wireshark, it appears as though the svn client is downloading the complete log history before printing out any log messages. Older svn clients do not have this issue (tested 1.6.17 and 1.7) Thanks, Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866
Re: Upgrade Subversion Repository from 1.5 into 1.8
On 12/16/2013 9:03 AM, Krishnamoorthi Gopal wrote: Thanks for your clarification pavel.. If i used existing repositories in Subversion 1.8 then how can i benefit features in new version.. Shall i use commands like "svnadmin Upgrade" to upgrade my existing repos into latest.. As Mark says, "svnadmin dump" and "svnadmin load" cycle is the best way to upgrade older SVN repositories to 1.8 because it will completely convert it into 1.8 format (including the new space-saving additions to the repository format). However, you don't have to do it all at once. You could start running SVN 1.8 on the server, then upgrade the individual repositories to the 1.8 format at your leisure. We spread our migration out over a few weeks (going from 1.6 to 1.8 format). So during the migration period we had a mix of repository formats on the server. Client-side working copies, however, are much more all-or-nothing. When the client moves to 1.8, all of the working copies also have to be upgraded to 1.8. And we still have a few 1.6 and 1.7 clients talking to our 1.8 server. Naturally, you should be making good backups of your SVN repositories daily. And the dump/load cycle is a good time to copy the dump files off to long-term storage.
Re: "svn log --limit" very slow with 1.8 client and 1.4 server
Peter Harris writes: > https://subversion.apache.org/reporting-issues.html directed me to > report issues to this mailing list. > > With svn 1.8.x (tested 1.8.3 and 1.8.5), "svn log" is very slow against > older svnserve (tested 1.4.6) when specifying any path other than the > root of the repository. > > eg. > > $ time svn log -l1 svn://host/repo > /dev/null > > real 0m0.039s > user 0m0.008s > sys 0m0.011s > > $ time svn log -l1 svn://host/repo/trunk > /dev/null > > real 5m55.153s > user 0m0.670s > sys 0m0.197s > > > This is a repository with about 35k revisions. From a glance at > wireshark, it appears as though the svn client is downloading the > complete log history before printing out any log messages. > > Older svn clients do not have this issue (tested 1.6.17 and 1.7) I can reproduce this. The svn_client_log6 function is using svn_ra_get_location_segments before calling svn_ra_get_log3 when asked for log on paths other than the repository root. There is no server side support for get-location-segments on older serves and svn_ra_get_location_segments falls back to deriving it from the whole repository log. This means that the client log implementation gets the whole repository log before making a second log request for the partial log that is required. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: "svn log --limit" very slow with 1.8 client and 1.4 server
Philip Martin writes: > Peter Harris writes: > >> https://subversion.apache.org/reporting-issues.html directed me to >> report issues to this mailing list. >> >> With svn 1.8.x (tested 1.8.3 and 1.8.5), "svn log" is very slow against >> older svnserve (tested 1.4.6) when specifying any path other than the >> root of the repository. > > I can reproduce this. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4458 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: "svn log --limit" very slow with 1.8 client and 1.4 server
On 2013-12-17 12:33, Philip Martin wrote: > Philip Martin writes: > >> Peter Harris writes: >> >>> With svn 1.8.x (tested 1.8.3 and 1.8.5), "svn log" is very slow against >>> older svnserve (tested 1.4.6) when specifying any path other than the >>> root of the repository. >> >> I can reproduce this. > > I've raised > > http://subversion.tigris.org/issues/show_bug.cgi?id=4458 Thanks. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866
Fork and merge individual files
Does subversion provide a way to fork and merge individual files stored in various points within a repository? If it does, can anyone provide a small example showcasing this feature? Thanks, Zé
Re: Fork and merge individual files
On Dec 17, 2013, at 13:56, Zé wrote: > Does subversion provide a way to fork and merge individual files stored in > various points within a repository? If it does, can anyone provide a small > example showcasing this feature? Subversion does not have a “fork” command but it does have a “copy” command, and yes you can copy individual files (or entire directories) from any point in the repository’s history. For example, if you have a working copy of the MacPorts portfiles collection: $ svn checkout https://svn.macports.org/repository/macports/trunk/dports $ cd dports The libpng portfile is currently at version 1.5.x but let’s say for whatever reason you wanted to make a new portfile for the old 1.2.x version. Using: $ svn log graphics/libpng —limit 30 I discovered that the last revision when that portfile used version 1.2.x was r71090. So as a first step of making a new libpng12 portfile I could: $ svn copy graphics/libpng@71090 graphics/libpng12 Now there’s a new directory graphics/libpng12 containing what graphics/libpng contained back in r71090 three years ago. Then I would edit the files in graphics/libpng12 further and test them before committing them. My example shows copying an old directory, but if you wanted to copy only a single file you could do it the same way. My example could be described as “forking” an old version, but I didn’t show merging. I suppose if I had made a change to libpng and wanted to merge it back to libpng12 I could do that, in the usual way, assuming the files weren’t too different from one another. If they were very different, I could still merge, but might encounter a conflict, which I would then have to resolve. Often in MacPorts, since individual changes to our portfiles are fairly small, I just make the same change manually to each portfile that needs it and commit them, often together in the same commit, rather than bother with merging.
