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
The administrator has disabled public write access. Re:Multi branch / distributed development support 9 Hours, 56 Minutes ago I guess the following closes this topic:
www.joelonsoftware.com/items/2010/03/17.html
I can’t tell you how many Subversion users have told me the following story: “We tried to branch our code, and that worked fine. But when it came time to merge back, it was a complete nightmare and we had to practically reapply every change by hand, and we swore never again and we developed a new way of developing software using if statements instead of branches.”
And more here
hginit.com/00.html
Almost every Subversion team I’ve spoken to has told me some variation on the very same story. This story is so common I should just name it “Subversion Story #1.” The story is this: at some point, they tried to branch their code, usually so that the shipping version which they gave their customers can be branched off separately from the version that the developers are playing with. And every team has told me that when they tried this, it worked fine, until they had to merge, and then it was a nightmare. What should have been a five minute process ended up with six programmers around a single computer working for two weeks trying to manually reapply every single bug fix from the stable build back into the development build.
And almost every Subversion team told me that they vowed “never again,” and they swore off branches.
THE END
The administrator has disabled public write access. Re:Multi branch / distributed development support 2 Hours, 41 Minutes ago We've been using SVN branching for a long time. Now we only work on release branches and never use the trunk - for us the trunk is like an appendix, it is there, but not needed. We only merge "upstream". Since we may be working on two major releases and a couple of patches for the same application, we rely on branches so we can work concurrently on different releases of the same code. We have had little problem merging from the earlier releases to the later release branches.
I think two of our keys is we merge daily. This ensures developers are working on the latest code. It also keeps conflicts to a minimum.
We also have centralized our merges. Only one person does the merges on a daily basis and runs a CI build immediately after the merge. That person can resolve most merge conflicts but will call on individual developers to work out any "tricky" conflicts.
We've been using this system for over 5 years and have never lost or mangled a change in all that time.
The administrator has disabled public write access. Vision without action is a daydream. Action without vision is a nightmare.
Japanese Proverb
T. V. Loy
Configuration Manager
View the original article here
No comments:
Post a Comment