On Fri, Sep 09, 2011 at 03:00:53PM -0400, David Carson wrote:
> OK, so let's try again. I've merged a change from another branch, which is
> a commit with a single file changed. The result is much better, but let me
> verify that I understand my results:
> - file a/b/c/foo.c shows the file changes -- OK
> - file a/b/c/foo.c also contains svn:mergeinfo changes -- I assume this is
> because it happens to be one of the many files that got contaminated with
> the property prior to this test. So, since it is part of the changeset for
> my merge, the prop has to be updated too.
> - <top-level> directory (call it TLD/) contains svn:mergeinfo changes -- OK
> - TLD/a also contains svn:mergeinfo changes -- Same as above. Directory
> TLD/a is one of the directories which was previously contaminated, and since
> this path is 'involved' in the change, the prop has to be updated. I
> wouldn't say the path really involved, except that it is the path on wich
> foo.c sits. After all, TLD/a/ is not itself changed. Nonetheless, I can
> live with this.
This is because it's not about which "objects" (as you called them ealier)
are affected by the merge, but which subtrees of the merge target are affected.
In your case, it looks as if the target of the merge is the working copy
root. An affected subtree of the root is a, an affected subtree
of a is b, and so on, until you get to foo.c.
If you merge from ^/branch/a/b/c/foo.c into wc-path/a/b/c/foo.c
only foo.c should receive mergeinfo updates, because it is the
merge target and has no children.
> Now, are there any tools to aid in cleanup of the mess? Besides the large
> number of files/dirs with the prop attached, the prop itself has a large
> number of paths to contend with.
There doesn't seem to be any officially sanctioned script.
There are various scripts people have written and posted to this list.
One is here: http://svn.haxx.se/dev/archive-2009-05/0438.shtml
You could try the archive search on svn.haxx.se -- maybe you'll find
something useful.
However, I would say that the need for such a script implies a lack
of functionality in Subversion itself. 'svn merge' does try to elide
mergeinfo when subtree mergeinfo becomes redundant, but AFAIK the
current implementation is a bit simplistic.
It would help if you could present examples where elision does not
work for you, so we can fix 'svn merge'.
We could allow the existing elision code to be invoked without running
a merge. An option like --elide-mergeinfo could be added to the
'svn mergeinfo' command for this purpose. Would this be useful?
Received on 2011-09-10 00:40:50 CEST