mergeinfo not inherrited when I thought it should
Hello, In a quick test, we have a project which has the following structure: /trunk/project/subfolder/file Next, we create a branch from /trunk/project to /branches/project/branch1/ We edit file on trunk a first time, changing line1 and commit Inside branch1, we do a merge from trunk. This creates mergeinfo on /branches/project/branch1 We edit file on trunk a second time, reverting line1, changing line2 and commit Inside branch1/subfolder, we do a merge from trunk/subfolder. This last step ignores the mergeinfo on /branches/project/branch1/ and merges all revisions again since we made the branch. I thought inherrited mergeinfo would be used here to see that a first part of the revision range did not need to be merged again. However, this does not happen. The result is that we merge the combination of the 2 edits, which is only changing line2. However, we had already merged the change to line1, so the revert on line1 should have been merged too. See attachment for a reproduction scenario. Is this scenario supposed to be handled by SVN ? We are in a corporate environment, using 1.5.1. Is the above scenario known to be handled correctly in later versions? Is it a known issue? Do I try something which is not supported by SVN? Kind regards, Pieter-Jan Busschaert mkdir mergetest cd mergetest mkdir trunk cd trunk mkdir subdir cd subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 02" >> test.txt echo "" >> test.txt echo "line3 01" >> test.txt cd .. cd .. svn import https:///mergetest cd .. rm -rf mergetest svn co https:///mergetest mergetest cd mergetest svn up svn cp https:///mergetest/trunk https:///mergetest/branch svn up cd trunk/subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 02" >> test.txt echo "" >> test.txt echo "line3 02" >> test.txt svn ci cd ../.. cd branch svn merge https:///mergetest/trunk svn ci svn propget svn:mergeinfo . cd .. cd trunk/subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 03" >> test.txt echo "" >> test.txt echo "line3 01" >> test.txt svn ci cd ../.. cd branch/subdir svn propget svn:mergeinfo . svn propget svn:mergeinfo .. svn merge https:///mergetest/trunk/subdir svn propget svn:mergeinfo . svn propget svn:mergeinfo .. svn ci cd ../..
Re: mergeinfo not inherrited when I thought it should
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 > 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. > 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. Kind regards, Pieter-Jan
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 wrote: > On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert > 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 upda
Re: mergeinfo not inherrited when I thought it should
Hello, >> 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. Yes, I noticed that. I had put the output of svn stat -v in the reproduction scenario. I am not really certain why you say "so svn can be sure it has consistent information". I always thought if my working revision was >= last changed revision, then I had everything up-to-date. [however, see below] >> 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? > > 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. OK, that was an interesting section to read. However, from my experience, the sentence "Admittedly both of these example are a bit contrived, and you may never run into anything like them." is a bit far-fetched. Without the rule to only merge on top-level, you run into this frequently. Now, I have been able to narrow down the necessary svn update a bit further. Same reproduction script as before, just before the "bad" second merge. r5 is the first merge which: (1) updated the file /branch/subdir/test.txt and (2) added mergeinfo on /branch. $ svn stat -u -v 66 pjbu trunk/subdir/test.txt 32 pjbu trunk/subdir 32 pjbu trunk 55 pjbu branch/subdir/test.txt 32 pjbu branch/subdir <=== this causes the wrong mergeinfo 55 pjbu branch 33 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r4 <=== was already merged, it is in svn:mergeinfo on /branch @ r5 r6 $ svn up -r 5 --depth=empty branch/subdir At revision 5. <== doesn't change anything $ svn stat -u -v 66 pjbu trunk/subdir/test.txt 32 pjbu trunk/subdir 32 pjbu trunk 55 pjbu branch/subdir<=== the last-commited rev in the repo also changed ??? 55 pjbu branch/subdir/test.txt 55 pjbu branch 33 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r6 < correct now Well, I can see how svn has trouble when merging into branch/subdir without that directory itself being atleast at the revision where the mergeinfo was added to its parent. However, there seems something strange with the notion of out-of-date on a directory. I thought the second column of revision numbers in svn stat -v was completely independent of the working copy status, but that doesn't seem to be the case. It's a pity all the improvements around tracking mergeinfo will only be included in 1.7, because I fear all the WC-NG developments will make our company even more reluctant to update to that version. Thanks for the help, Pieter-Jan
Re: mergeinfo not inherrited when I thought it should
>> $ svn up -r 5 --depth=empty branch/subdir >> At revision 5. <== doesn't change anything > > Yes it does. It changes the working revision of branch/subdir from 3 > to 5. Since this update didn't bring in new explicit mergeinfo on > branch/subdir, svn can now safely assume that the mergeinfo from > /branch can be inherited (before this update, it could not be sure > about that). OK. But if svn merge already contacts the repository when it doesn't find any mergeinfo in the WC, then I think it could contact the repository to automatically check for the above case too. >> However, there seems something strange with the notion of out-of-date >> on a directory. I thought the second column of revision numbers in svn >> stat -v was completely independent of the working copy status, but >> that doesn't seem to be the case. > > Indeed, the second column is only information present in the working > copy (it doesn't contact the repository to see that the last changed > rev over there is higher than what it has in the working copy). Thanks for the clarification, I thought the combination of -u and -v would show me the state in the repository, but this is clearly not the case. I also noticed directories get the highest last-changed rev-number of any of their children, even if nothing really changed on the directory properties itself. These 2 things got me confused... >> It's a pity all the improvements around tracking mergeinfo will only >> be included in 1.7, because I fear all the WC-NG developments will >> make our company even more reluctant to update to that version. > > The rewrite was/is absolutely necessary to go forward. I know and I will try to keep some of these testcases around to check with 1.7. Kind regards, Pieter-Jan
