You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pieter-Jan Busschaert <pi...@gmail.com> on 2010/10/29 16:45:36 UTC
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
RE: mergeinfo not inherrited when I thought it should
Posted by Bob Archer <Bo...@amsi.com>.
> 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.
Did you commit the first merge?
BTW: To minimize the merge info propgation you really just always merge from /trunk/project into your branch. If you only want a specific revision you can specify it... but still you want to keep all the mergeinfo in /branches/project/branch1 if you can... or else merges will start changing all kinds of properties on all your child nodes.
> 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?
There were many merge issues fixed after 1.5.1.. you should get to the latest 1.6... or at the very least the latest 1.5.
BOb
Re: mergeinfo not inherrited when I thought it should
Posted by Pieter-Jan Busschaert <pi...@gmail.com>.
>> $ 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
Re: mergeinfo not inherrited when I thought it should
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Nov 4, 2010 at 2:00 PM, Pieter-Jan Busschaert
<pi...@gmail.com> wrote:
> 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.
Ok, maybe this is not that extremely rare (however, this is the first
report I see about this on the users list, so it's not that common
either).
> 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
> 6 6 pjbu trunk/subdir/test.txt
> 3 2 pjbu trunk/subdir
> 3 2 pjbu trunk
> 5 5 pjbu branch/subdir/test.txt
> 3 2 pjbu branch/subdir
> <=== this causes the wrong mergeinfo
> 5 5 pjbu branch
> 3 3 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
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).
> $ svn stat -u -v
> 6 6 pjbu trunk/subdir/test.txt
> 3 2 pjbu trunk/subdir
> 3 2 pjbu trunk
> 5 5 pjbu branch/subdir <===
> the last-commited rev in the repo also changed ???
Hm, maybe that's because it can now inherit the mergeinfo from
/branch, which was introduced in r5. So in effect, this branch/subdir
*was* changed in r5, namely it inherits new mergeinfo from branch.
> 5 5 pjbu branch/subdir/test.txt
> 5 5 pjbu branch
> 3 3 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.
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).
> 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.
Why? Because it's new technology, a rewrite of some piece that has
already 10 years of maturity (and numerous bugfixes and optimizations)
under its belt? And they fear a lot of instability because of this?
If so, I can certainly understand this argument. New stuff introduces
new bugs, and it will all be brand new, so ... However, WC-1 was
really at the end of its powers. Some problems (and the number of them
was steadily increasing) were really becoming extremely difficult to
solve. The rewrite was/is absolutely necessary to go forward. It will
help fix a lot of problems (like this one), and open up possibilities
for much more interesting features in the future (like offline
commits, checkpointing, better tree conflict handling, better tracking
of renames, better merge tracking, ... a lot of these things depend on
WC-NG).
The only thing I can say is: please help making the 1.7 release as
stable/bugfree as possible, by testing it as soon as you can. Most of
the stuff is working-copy related, so you can easily set up a
throw-away working copy to test some things in your company.
If I understood correctly, the developers will work together with some
of the binary distributors to set up a beta program, where betas and
release candidates will be distributed as compiled binaries for
various platforms, to get as much test coverage as possible before the
release. So, if those betas start appearing: please help testing them,
and report bugs as soon as you can.
Cheers,
--
Johan
Re: mergeinfo not inherrited when I thought it should
Posted by Pieter-Jan Busschaert <pi...@gmail.com>.
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
6 6 pjbu trunk/subdir/test.txt
3 2 pjbu trunk/subdir
3 2 pjbu trunk
5 5 pjbu branch/subdir/test.txt
3 2 pjbu branch/subdir
<=== this causes the wrong mergeinfo
5 5 pjbu branch
3 3 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
6 6 pjbu trunk/subdir/test.txt
3 2 pjbu trunk/subdir
3 2 pjbu trunk
5 5 pjbu branch/subdir <===
the last-commited rev in the repo also changed ???
5 5 pjbu branch/subdir/test.txt
5 5 pjbu branch
3 3 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
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Nov 4, 2010 at 12:30 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> 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
>
> One of the plans being tossed around for 1.7 is to make merge throw an
> error if the working copy is not at a single revision. So you will
> have to run svn up before you can merge or pass a new option to the
> merge command that tells it you want to ignore this best practice.
>
> Last I knew, patches were still being exchanged for this. I do not
> think it has been committed to trunk yet.
Yes, this has already been committed to trunk:
http://svn.apache.org/viewvc?view=revision&revision=1027970 ("Disallow
merges into mixed-revision working copies by default.")
Cheers,
--
Johan
Re: mergeinfo not inherrited when I thought it should
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> 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
One of the plans being tossed around for 1.7 is to make merge throw an
error if the working copy is not at a single revision. So you will
have to run svn up before you can merge or pass a new option to the
merge command that tells it you want to ignore this best practice.
Last I knew, patches were still being exchanged for this. I do not
think it has been committed to trunk yet.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: mergeinfo not inherrited when I thought it should
Posted by Johan Corveleyn <jc...@gmail.com>.
[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
<pi...@gmail.com> wrote:
> On 3 November 2010 10:17, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
>> <pi...@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
Re: mergeinfo not inherrited when I thought it should
Posted by Pieter-Jan Busschaert <pi...@gmail.com>.
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 <jc...@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
> <pi...@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
>
Re: mergeinfo not inherrited when I thought it should
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 17:18:54 +0100:
> On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> >> (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).
> >
> > That surprised me a little, but a quick test with current trunk[1]
> > confirms:
>
> Yes, it's kind of easy to miss, because there is no explicit issue in
> the issue tracker for this AFAIK. But I vaguely remember some mail
> threads on the dev-list about this, and saw it mentioned in the
> description of another issue about mergeinfo ([1]).
There's quite a bit of traffic about mergeinfo. I try to follow the
developments to some degree, but I missed (or forgot) about this change.
> This refers to
> revision r878767 ([2]), which is apparently the reintegration of a
> feature branch "subtree-mergeinfo", which was made specifically for
> developing this feature.
>
Thanks for the digging!
> Since this is quite a big issue for a lot of users, it's important not
> to forget about this change when the time comes to write the release
> notes for 1.7. Maybe it should be mentioned on the roadmap page (as
> one of the finished items), or an issue should be created in the issue
> tracker?
>
(without expressing an opinion as to which option is preferable,) another
option is to create a stub section in
/site/publish/docs/release-notes/1.7.html.
btw, I think there have been more release-notes-worthy merge-tracking
changes than just this one.
> Cheers,
> --
> Johan
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3577
> [2] http://svn.apache.org/viewvc?view=revision&revision=878767
Re: mergeinfo not inherrited when I thought it should
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
>> (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).
>
> That surprised me a little, but a quick test with current trunk[1]
> confirms:
Yes, it's kind of easy to miss, because there is no explicit issue in
the issue tracker for this AFAIK. But I vaguely remember some mail
threads on the dev-list about this, and saw it mentioned in the
description of another issue about mergeinfo ([1]). This refers to
revision r878767 ([2]), which is apparently the reintegration of a
feature branch "subtree-mergeinfo", which was made specifically for
developing this feature.
Since this is quite a big issue for a lot of users, it's important not
to forget about this change when the time comes to write the release
notes for 1.7. Maybe it should be mentioned on the roadmap page (as
one of the finished items), or an issue should be created in the issue
tracker?
Cheers,
--
Johan
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3577
[2] http://svn.apache.org/viewvc?view=revision&revision=878767
Re: mergeinfo not inherrited when I thought it should
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> (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).
That surprised me a little, but a quick test with current trunk[1]
confirms:
% cd ~/src/svn/16x/
% $svn merge -c N ../trunk
...
% $svn pg -vR svn:mergeinfo . | grep Properties
Properties on '.':
Properties on 'subversion/tests/cmdline/merge_tests.py':
Properties on 'CHANGES':
% $svn st -q
M .
M subversion/include/svn_client.h
C subversion/tests/cmdline/export_tests.py
C subversion/svn/export-cmd.c
M subversion/libsvn_client/export.c
% $svn st -q | egrep 'CHANGES|merge_tests'
%
Nice.
Daniel
[1] I'm using a build from the performance branch as my "current trunk"
build these days.
Re: mergeinfo not inherrited when I thought it should
Posted by Pieter-Jan Busschaert <pi...@gmail.com>.
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 <jc...@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
> <pi...@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
>
Re: mergeinfo not inherrited when I thought it should
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
<pi...@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
Re: mergeinfo not inherrited when I thought it should
Posted by Pieter-Jan Busschaert <pi...@gmail.com>.
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
Posted by Giulio Troccoli <Gi...@uk.linedata.com>.
>
> 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.
Do you mean trunk/project/subfolder here?
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.
Merges from trunk to branch and vice-versa should always be done from the root of the project (in your case branches/project/branch1)
>
> 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?
I don't think so, as I think Subversion did the correct thing, given the information it has.
However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was not particularly good with merging.
> Is it a known issue?
> Do I try something which is not supported by SVN?
>
>
> Kind regards,
>
> Pieter-Jan Busschaert
>
Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
RE: mergeinfo not inherrited when I thought it should
Posted by Giulio Troccoli <Gi...@uk.linedata.com>.
>
> 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.
Do you mean trunk/project/subfolder here?
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.
Merges from trunk to branch and vice-versa should always be done from the root of the project (in your case branches/project/branch1)
>
> 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?
I don't think so, as I think Subversion did the correct thing, given the information it has.
However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was not particularly good with merging.
> Is it a known issue?
> Do I try something which is not supported by SVN?
>
>
> Kind regards,
>
> Pieter-Jan Busschaert
>
Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03