>Basically I had a lot of subtree mergeinfo from people doing merges,
and I merged a revision from one branch. I ran the merge at the top of
my WC. The result was that the entire WC's mergeinfo was updated to
reflect the branch and revision merged, even if nothing under any given
path was updated. To illustrate, I had something like this:
>
>/trunk (has mergeinfo)
> /A (has mergeinfo)
> /B (has mergeinfo)
> /C (has mergeinfo)
>/branches
> /1
> /A
> /B
> /C
>
>Revision X affects files under /branches/1/A. When I merge revision X
into my WC at /trunk, I see mergeinfo changes on /trunk, /trunk/A,
/trunk/B, and /trunk/C. It would be find if the existing mergeinfo was
being elided into /trunk itself and removed from /trunk/B and /trunk/C,
but that's not happening. Instead it's just adding more mergeinfo to
reflect the merge from /branches/1. I have no idea why /trunk/B and
/trunk/C need this, since they aren't directly affected by the merge.
>
>I'm also not noticing any performance improvement here; it still took
several minutes to do this operation. I thought I would see a
noticeable improvement over the 1.5.2. Note that I didn't time the
operation.
>
>Can anyone explain whether I'm doing something wrong, or whether we
will eventually see an improvement here? Do I need to do a dump/load to
see this? Or do a full new checkout? I did my initial checkout using
Svn 1.6.1.
>
>--Todd
Before you do the merge is the mergeinfo property on those
files/folders? It sounds like what you are saying is YES this is the
case. If so, they (all items with existing mergeinfo properties) will be
updated every time you do a merge. That is by design. You will need to
remove that property manually after you insure all the correct merge
info is on the parent project folder. Once you do that the mergeinfo
should only be created in the parent folder with the most recent
versions.
Also, I don't think any performance improvements were made in the last
few releases. What we here is that version 1.7 will see a lot of perf
improvements due to the next gen working copy stuff that stores the
metadata in a sqlite database rather than the file system.
Bob
Yes, those files/folders have mergeinfo before the merge. I guess I am
failing to understand why this "by design" behavior is a good thing.
Any time somebody does a merge at the level of a directory containing no
mergeinfo, they will get mergeinfo on that directory. And thereafter,
every merge at a higher level will update that mergeinfo.
From what I read about elision, this is not what is supposed to happen.
Here is what I'm talking about, from the functional spec at
http://subversion.tigris.org/merge-tracking/func-spec.html :
The merge info on 'A_COPY_2/B/E' elides to 'A_COPY_2' because the only
differences between the merge source paths on each is 'B/E' which is the
same as the relative path difference between 'A_COPY_2/B/E' and
'A_COPY_2'.
But here, instead of eliding mergeinfo from /trunk/B up to /trunk, BOTH
/trunk and /trunk/B get mergeinfo. This proliferation seems to never
end unless you painstakingly go through and manually clean it up, and
hope that you don't wipe out something important which will later result
in a bad merge. In addition, the result of this proliferation at my
company is that users simply refuse to commit the mergeinfo changes at
all, or they manually pare it down (in the case I sited, only /trunk
needs a mergeinfo update). Or they merge at subtrees for better
performance and less clutter, but create more mergeinfo which makes it
harder for those of us who merge at the root.
I also don't understand if there is a safe way to manually elide the
mergeinfo, rather than deleting it. Presumably it's there for a reason
so outright deletion seems like a bad idea. I would love it if there
was a script I could just run to do this, but the only one I saw simply
deleted mergeinfo.
Is there a use case where I can merge a subtree, getting mergeinfo on
the subtree (/trunk/A), and then merge at the root of the WC (/trunk),
and have the subtree's mergeinfo actually elide up to the root (/trunk)
where appropriate?
Regarding performance, here is what I see in the change log that I
expected to improve performance:
1.6.1:
* improve 'svn merge' performance with subtree mergeinfo (r36444)
1.5.3:
* Reuse network sessions during 'svn merge', improving performance
(r33476)
* Greatly improve merge performance (r29969, r32463, r33013, -016,
-022, -112)
Perhaps the bottlenecks have in fact been resolved and all the time is
spent in scanning my entire WC for mergeinfo, consistent BASE versions,
and switched paths.
--Todd
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2401801
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-30 00:07:07 CEST