Subversion sees the revision you create during the merge between branches as a new change (which strictly speaking it is as there's no way to know that you did not take action to resolve conflicts for example). So, although it can 'see' that change 123 has been integrated it cannot know that the merge change can be taken on faith, as it were.
This is where you might get conflicts when you 'drop' the source branches. Subversion sees, and ignores, 123 but 233 is a new change (just like the problem you have when bringing a --reintegrated branch back to life where the revision created on trunk is seen as a 'poison' revision in any subsequent integration from trunk to branch). You can always 'fix' the problem with the --record-only trick to tell Subversion to ignore some revisions during the --reintegrate. Merge with a --record only from the branch into the trunk will essentially tell Subversion that you are happy that the change is already dealt with.
Using the previous example, suppose the merge between branches resulted in revision 233 being created and I then drop the sourcebranch into the trunk (--reintegrate), I can forewarn Subversion that 233 should also be ignored in any future trunk merge using the --record-only merge technique. This should only be used if 233 was created without any incident (no additional action taken when merging between branches, otherwise I may overlook some legitimate integration issues).
No tool can reliably and automatically account for this sort of thing because during the merge between branches I may have to perform all sorts of integration actions both resolving direct conflicts and also potentially performing changes to different parts of the code base to accommodate the integrated change (123). The tool can only 'blindly' resolve the record that change 123 has been integrated with 233 (which Subversion does), it cannot understand any other actions taken in 233 and so will have to account for that in the drop to trunk. This requires a human to say 'well, actually 233 has no special actions in it, so go ahead and ignore it'. I guess a tool could look at 233 and infer that, if all the deltas in 123 and 233 are identical, then 233=123, but beyond that I think a person is needed to make a judgement call as to whether 233 can be ignored completely, ignored in part, or not ignored at all.
There are ways to minimise problems of this sort (by limiting the scope of changes, making changes as small as possible, integrating changes in parts; those that need no special actions and those that do, etc.) but that's all a bit beyond this thread or my capacity to explain in a single post
Hope that all makes sense
View the original article here
No comments:
Post a Comment