[small nit: please don't top-post on this list (i.e. put your reply at
the bottom or inline, not above the text you're replying to).]
On Wed, Nov 3, 2010 at 3:20 PM, Pieter-Jan Busschaert
<pieterjan.busschaert_at_gmail.com> wrote:
> 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
>>
> 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.
I think this is known "as-designed" behavior, because of the
mixed-revision working copy system. Some nodes in your working copy
may be at different revisions than others (if you commit a change to
^/parent/child, child will be at a new working revision, but parent's
working revision will not be "bumped" automatically, because
subversion doesn't know if other changes occurred at or below parent
which would require it to be fully updated). So, even though *you*
know that it isn't out-of-date semantically, for *svn* it is still
out-of-date because its "working revision" is not as recent as the
rest of the working copy. The full update at the top-level brings
everything at the same working revision.
You should take a look at this chapter from the book, for some general
understanding of mixed-revision working copies:
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
More below ...
> 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.
Try "svn stat -v", and you'll see the different working revisions of
the files and dirs in the working copy. It's the out-of-date working
revision that is actually causing this. Updating it brings it all at
the same level, so svn can be sure that it has consistent information.
You can also take a look at the "working revision" and "last changed
revision" of an individual file or dir with svn info (look at the
fields "Revision" and "Last Changed Rev").
> 2) svn update itself does not mention any updates, it just says "At revision 6."
Yup, and it probably bumped the working revisions to the latest revision.
> 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?
You should really read the entire section "Mixed Revision Working
Copies and Mergeinfo" of the article
http://www.collab.net/community/subversion/articles/merge-info.html. I
think the example near the end of that section describes a very
similar situation. I think you are seeing exactly the same thing here.
Cheers,
--
Johan
Received on 2010-11-04 09:55:46 CET