Re: mergeinfo not inherrited when I thought it should

Hi,

I tested with a reproduction scenario and found this:

A) If I do an svn update on the top-level WC before the merge command,
the merge goes through OK and I can checkin.
B) If I don't do an svn update on the top-level WC before the merge
command, the merge goes wrong and svn complains about out-of-date when
I do the checkin. A following svn update seems to not change anything
and I can checkin the wrong merge without problems.

There are a few things still not clear to me:
1) Before this svn update, svn stat -u shows nothing out-of-date, so
it's strange that an update makes any difference.
2) svn update itself does not mention any updates, it just says "At revision 6."
3) If I check the relevant svn:mergeinfo properties before / after
this svn update, I see no changes at all. However, if I check with the
svn mergeinfo command, then I do see a change after the update. What
else is being used to calculate the actual mergeinfo?
4) If I don't do the update before svn merge, why does svn complain
about out-of-date at checkin instead of at the merge itself?

See attachment for reproduction script + output for both cases.

Kind regards and thanks for the help,

Pieter-Jan

On 3 November 2010 10:17, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
> <pieterjan.busschaert_at_gmail.com> wrote:
>> Hello,
>>
>> Here is some more information:
>>
>>>> Inside branch1/subfolder, we do a merge from trunk/subfolder.
>>>
>>> Do you mean trunk/project/subfolder here?
>>
>> yes
>>
>>> Anyway, branch1/subfolder does not have any mergeinfo,
>>> since the previous merge was done on branch1. So Subversion
>>> does not know that you have already merged the changes to line 1.
>>
>> Correct, but isn't SVN supposed to crawl up the tree to find
>> mergeinfo? I thought this was the most simple usecase of inherited
>> mergeinfo, which is described in various places, for instance here:
>> http://help.collab.net/index.jsp?topic=/faq/mergeinfo.html
>
> Yes, you are absolutely right. Mergeinfo is normally inherited, so any
> mergeinfo set on the branch1 folder applies to the entire subtree (and
> svn indeed crawls up the tree to find all the mergeinfo that applies).
> Except if the mergeinfo is marked with an asterisk '*', which means
> "non-inheritable mergeinfo". For more in-depth information about
> mergeinfo, see [1].
>
>>> Merges from trunk to branch and vice-versa should always be done
>>> from the root of the project (in your case branches/project/branch1)
>>
>> I can not believe this is true.  I can not control the other users and
>> I have had reports of similar issues from a few different users here,
>> so it seems a real use case.
>
> Well, it's *recommended* to do merges always from the project root,
> but it's not required. SVN supports so-called "subtree merges" (which
> have the potential to only merge part of a revision).
>
> The reason it's recommended to do merges from the project root, is
> that it avoids explicit mergeinfo all over your tree. For every
> subtree merge, SVN records explicit mergeinfo on that subtree root.
> This means that that subtree will no longer inherit mergeinfo from
> higher up the tree. For this reason, explicit mergeinfo needs to be
> maintained all the time by SVN (because it will no longer crawl up
> from that point). Every subsequent merge at the project root causes
> those explicit-mergeinfo-paths to have their mergeinfo properties
> updated, even if they are not affected by the merge, which can be
> quite confusing to users. Other than that, subtree merges work just
> fine in SVN, just because of the explicit mergeinfo on the subtrees.
>
> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
> not-affected-subtrees will no longer have their mergeinfo updated all
> the time, only if they are affected by the merge).
>
>>> I don't think so, as I think Subversion did the correct thing, given the information it has.
>>
>> Well, I still think it did not do the correct thing, as it had more
>> info available than it actually used.
>>
>>> However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was not particularly good with merging.
>>
>> I have just tested with 1.6.13 on a test pc and it behaves exactly the same.
>>
>>
>>
>> By reading the details of inherited mergeinfo in the collabnet FAQ,
>> maybe the bug is because mergeinfo is not up to date in the working
>> copy and SVN uses that instead of contacting the repository. If this
>> is the case, I would expect SVN to give me a "please update" warning
>> when I do the merge command.
>
> Yes, maybe that's the problem. Can you retest this with an update at
> the right place, to see if the problem still occurs?
>
> Maybe you should check out the section "Mixed Revision Working Copies
> and Mergeinfo" in the above mentioned article [1], to see if it
> describes what you're seeing.
>
> If that's the case, you are probably right about the warning. I think
> this is being addressed in the upcoming 1.7 as well (see [2] and [3]).
>
> If the problem is something else, please try to come up with a simple
> reproduction recipe, starting with the creation of an empty repository
> (svnadmin create ...), demonstrating the problem.
>
> Cheers,
> --
> Johan
>
> [1] http://www.collab.net/community/subversion/articles/merge-info.html
> [2] http://svn.haxx.se/dev/archive-2010-10/0000.shtml
> [3] http://svn.apache.org/viewvc?view=revision&revision=1027970
>