On Fri, Sep 9, 2011 at 6:40 PM, Stefan Sperling <stsp_at_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.
Received on 2011-09-12 17:52:42 CEST