Are you able to get a feel for how the cost (in time) is distributed across
the operation?
Attached is a little Python script I wrote some time ago to assist with
answering questions of this nature. You'd use it by piping the output of
'svn merge' into, preferably using its --long and --diff options. Here's a
little example of its use:
% svn st | linestamp.py --long --diff
[Thu Jun 26 08:24:22 2008 00000000000.0000] [ START TIME
]--------------------------------------------
[Thu Jun 26 08:24:23 2008 00000000000.9023] ? install.sh
[Thu Jun 26 08:24:23 2008 00000000000.0047] ? PATCH2
[Thu Jun 26 08:24:23 2008 00000000000.0042] ? PATCHES
[Thu Jun 26 08:24:23 2008 00000000000.0001] X templates-contrib
[Thu Jun 26 08:24:23 2008 00000000000.0001] ? REMOVE
[Thu Jun 26 08:24:23 2008 00000000000.0001] ? PATCH
[Thu Jun 26 08:24:23 2008 00000000000.0001] ? testpipes.py
[Thu Jun 26 08:24:24 2008 00000000000.2139] [ END TIME
]----------------------------------------------
Anyway, if you have Python on both systems, perhaps you could give this a
shot, repeating your two merges and revealing the linestamp output here.
(Feel free to anonymize any sensitive paths in the output if necessary.)
J J wrote:
> Can I know about the working copy layout? I mean is your merge target is
> straight forward checkout with no 'switched child'.
>
>> Normal checkout, nothing is switched, no externals.
>
> Do you have a child with some mergeinfo on its own? If so some amount of
> work should be done by the client to handle this case.
>
>> If by child you mean a sub directory of the branch I checked out, I
>> don't think there is any merge info specific to a sub directory.
>> However, when I perform the initial merge of the entire branch with no
>> mergeinfo at all on the destination branch, after the 12 minute
>> process completes my mergeinfo looks like this. Note the merge was
>> from RB-25.x to RB-26.x. (I've actually merged some additional
>> changes from RB-25.x to RB-26.x since then, but you get the idea)
>
>> C:\work\15testing\RB-26.x>svn pl -v .
>> Properties on '.':
>> svn:mergeinfo : /branches/RB-19.4.x:7-9
>> /branches/RB-20.x:10-521
>> /branches/RB-21.0.2.x:1080-1086
>> /branches/RB-21.x:522-1005
>> /branches/RB-22.x:1087-1480
>> /branches/RB-23.1.1.x:2227-2378
>> /branches/RB-23.1.x:1914-2212
>> /branches/RB-23.x:1481-1516
>> /branches/RB-24.x:1902-1913
>> /branches/RB-25.x:2379-2758
>> /branches/TASK-eES-RB-21.x:1006-1079
>> /branches/TASK-eES-RB-23.x:1517-1901
>> /ees/branches/RB-25.x:2763-2773
>> /tags/REL-23.1.0.35:2213-2226
>> /trunk:2-6
>
>> I don't understand how the new merge tracking code works. We had
>> performed many merges in the past using svnmerge.py, but I removed
>> svnmerge.py's merge info before merging anything with svn 1.5.0. I
>> doubt that affects anything since the property names are different.
>
>> I assume all of these branches adds a lot of work, and I'd like to
>> understand why it recorded all of that when I only merged a single
>> branch. That doesn't explain the difference in time between Windows
>> and UNIX though.
>
> Can you try merge with --ignore-ancestry(Warning: it won't track merges,
> but can be faster, so that we can compare and contrast for the time
> differences)?
>
>> I have already merged other changes since then. But here is a test
>> case where nothing needs to be merged (i.e. all changes from RB-25.x
>> are already on RB-26.x).
>
>> With --ignore-ancestry
>
>> Runs for a while and then spits out a bunch of skipped targets, some
>> conflicts and asks me to resolve. I'd send more specifics but I can't
>> post the path names to this list.
>
>> Without --ignore-ancestry
>
>> Runs for 14:59.79 and does nothing since no merge is necessary.
>
>
>> I'd be glad to perform other tests if you want me to.
>
>> Justin
>
> With regards
> Kamesh Jayachandran
>
>
> J J wrote:
>>>> Forgive me if this is bad form, but it occurred to me that this is
>>>> more of a dev question. Currently there are no responses from users.
>>>> Thanks.
>>>>
>>>> On Wed, Jun 25, 2008 at 10:07 AM, J J <eggsgloriouseggs_at_gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm seeing incredibly slow performance when performing a merge on
>>>>> Windows using the 1.5.0 client from CollabNet against a Solaris server
>>>>> running 1.5.0 on a repository that has had "svnadmin upgrade" and
>>>>> "svn-populate-node-origin-index" run against it. Performance isn't
>>>>> terribly fast on Solaris either, but much worse on Windows.
>>>>>
>>>>> I read through the thread at
>>>>> http://svn.haxx.se/dev/archive-2008-06/0687.shtml but wasn't sure if
>>>>> it is resolved in the final 1.5.0 build from CollabNet.
>>>>>
>>>>> Here are my elapsed times. The merge only merged 2 files in and had
>>>>> already been run once for the source branch, so the initial mergeinfo
>>>>> property was already set.
>>>>>
>>>>> Windows Elapsed Time: 12:23.11
>>>>> Solaris Elapsed Time: 1:19.12
>>>>>
>>>>> If this is the expected performance, are any improvements planned for
>>>>> the near future? This performance may be enough for me to put the
>>>>> breaks on upgrading our company to SVN 1.5.
>>>>>
>>>>> Thanks,
>>>>> Justin
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>>>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-06-26 20:18:03 CEST