On Fri, Sep 9, 2011 at 6:40 PM, Stefan Sperling <s...@elego.de> wrote:
> 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. > OK, then it seems to be working as I expect it to. > > 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. > Ironically, that is what got us in this mess in the first place (merging at various locations in the tree). I think what I want eventually is a tree where ONLY the top-level directory has any svn:mergeinfo. > > > 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? > Yes, I think such an option would probably be useful. What I really need, based on how much information is currently in my props, is something like: - try to elide (maybe using your new option) - output says you can't because you are missing a, b and c; suggests I use --record-only or do the missing merge if it is really missing Then I can iterate over this sequence until I succeed and the elision occurs. Thanks.
