Re: Slow merging of selected revisions
As a result of this new process, developers are doing a lot more local updates. How much of CPU this takes from the server? regards Emerson On 7 July 2010 12:10, emerson wrote: > We started to use a two tiered baseline approach, with a development > trunk and a stable branch. > Everyday we are doing promotions of selected changes based on > revisions, which might involve from 1 to >15 revisions in one go. > > Even dry-run sometimes takes more than 30 minutes to process one single file. > > We are using the "svn merge http://[repo] -c 333" command syntax. > > Our server is 1.4.4, and we are using 1.6.x clients. > We are in the process of updating to the latest version on the server, > is there anything I can try to improve the performance? > > thanks > Emerson >
Re: Slow merging of selected revisions
On Wed, Jul 7, 2010 at 09:41, emerson wrote: > As a result of this new process, developers are doing a lot more local > updates. How much of CPU this takes from the server? You (presumably) have access to your server; we do not. Log into the server and perform one of these tasks while monitoring the CPU utilization. There is no universal answer because everyone's data is different. > > On 7 July 2010 12:10, emerson wrote: >> We started to use a two tiered baseline approach, with a development >> trunk and a stable branch. >> Everyday we are doing promotions of selected changes based on >> revisions, which might involve from 1 to >15 revisions in one go. >> >> Even dry-run sometimes takes more than 30 minutes to process one single file. >> >> We are using the "svn merge http://[repo] -c 333" command syntax. >> >> Our server is 1.4.4, and we are using 1.6.x clients. >> We are in the process of updating to the latest version on the server, >> is there anything I can try to improve the performance? >> >> thanks >> Emerson >> >
RE: Slow merging of selected revisions
> From: emerson [mailto:echofloripa.y...@gmail.com] > > Even dry-run sometimes takes more than 30 minutes to process one single > file. > > We are using the "svn merge http://[repo] -c 333" command syntax. > > Our server is 1.4.4, and we are using 1.6.x clients. I believe we found the root cause of this problem. Please see this thread: (start) http://svn.haxx.se/dev/archive-2010-07/0040.shtml (middle) http://svn.haxx.se/dev/archive-2010-07/0101.shtml (end) http://svn.haxx.se/dev/archive-2010-07/0122.shtml The solution seems to be: Upgrade your server to 1.6. Upgrade your clients to 1.6. and Even though they say you shouldn't need this, dump & load your repo to upgrade it to 1.6. If you don't do this, the old revs which are slow in your repo will always remain slow. Moving forward, eventually you'll stop seeing the problem on a regular basis, as you begin using more and more consistently, just revs which were committed with 1.6. But the commit algorithm doesn't always diff against rev n-1, sometimes it diffs against rev n/2, which means ... Unless you do the dump & load, the problem will never entirely go away. The dump & load will take a really long time. Because it will systematically step on every single one of the bad revs.
