Dev: Automerge changes... finally worked out
I finally figured out the source of the problems with automerging of developer branches from the trunk (this was not an issue with developer branches based on branches/1.2).
The core issue that the 'svnmerge-integrated' property was being used for two conflicting purposes: to track the branches/1.2 fixes that had been forward-ported into the trunk and also to track the trunk changes that had been merged into the developer branch. Obviously this cannot work :-)
To solve the problem, the branches/1.2 forward-porting properties on trunk are no longer using the standard svnmerge property names; they are now called 'branch-1.2-merged' and 'branch-1.2-blocked', and there are _no_'svnmerge-integrated' or 'svnmerge-blocked' properties on the trunk. This means that forward-porting patches from branches/1.2 requires specifying the property names to svnmerge; see the
branching/merging page on asterisk.org for an example.
All new developers branches made from trunk should work with automerging without any problem, but existing branches have an issue: the developer branch contains a property 'svnmerge-integrated', but the trunk does not, and running 'svnmerge merge' will try to update that property, resulting in a conflict. To resolve this issue, for each branch that you maintain, you will need to manually use svnmerge to bring it up-to-date to at least revision 9163 (where the property was removed from the
trunk); from that point forward, automerge will be able to manage the merges for you.
In the meantime, you will probably start to receive conflict notices because your branches cannot be merged... but once we are past this issue, automerging should work well and should no longer generate 'false' conflicts like it was doing before.
Posted by: Kevin Fleming
The core issue that the 'svnmerge-integrated' property was being used for two conflicting purposes: to track the branches/1.2 fixes that had been forward-ported into the trunk and also to track the trunk changes that had been merged into the developer branch. Obviously this cannot work :-)
To solve the problem, the branches/1.2 forward-porting properties on trunk are no longer using the standard svnmerge property names; they are now called 'branch-1.2-merged' and 'branch-1.2-blocked', and there are _no_'svnmerge-integrated' or 'svnmerge-blocked' properties on the trunk. This means that forward-porting patches from branches/1.2 requires specifying the property names to svnmerge; see the
branching/merging page on asterisk.org for an example.
All new developers branches made from trunk should work with automerging without any problem, but existing branches have an issue: the developer branch contains a property 'svnmerge-integrated', but the trunk does not, and running 'svnmerge merge' will try to update that property, resulting in a conflict. To resolve this issue, for each branch that you maintain, you will need to manually use svnmerge to bring it up-to-date to at least revision 9163 (where the property was removed from the
trunk); from that point forward, automerge will be able to manage the merges for you.
In the meantime, you will probably start to receive conflict notices because your branches cannot be merged... but once we are past this issue, automerging should work well and should no longer generate 'false' conflicts like it was doing before.
Posted by: Kevin Fleming
posted by Dal at
8:34 PM
