Slow merging of selected revisions

[emerson <ec...@gmail.com>]

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

[Andy Levy <an...@gmail.com>]

On Wed, Jul 7, 2010 at 09:41, emerson <ec...@gmail.com> 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 <ec...@gmail.com> 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

[emerson <ec...@gmail.com>]

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 <ec...@gmail.com> 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

[Edward Ned Harvey <sv...@nedharvey.com>]

> From: emerson [mailto:echofloripa.yell@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.