> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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
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
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).
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.
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.
> 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.
>> On Wed, Jun 25, 2008 at 10:07 AM, J J <eggsgloriouseggs_at_gmail.com> wrote:
>>> 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.
>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-26 20:23:48 CEST