S
Simon L. Prinsloo
Guest
The example does use branches for development. They converge into the trunk - which is the "potential product" that goes through QA before the next release is branched off as a maintenance branch. The problem arise AFTER the branches converged, which they should do in the QA phase. It would be reckless to test each change independently and then hope they will play nice when moved to production. When the branches had an overlap, there are only a few sane options if one is held back: a) Hold back both. b) Restore QA to a point before the merge and merge only the selected change. Repeat all testing. Option a) is much cheaper than option b). In many cases option a) works, but I know from experience that every software house will often select option b) for cash flow reasons. All of that is fine and accepted as normal. The problem at hand is to detect such a overlap / conflict, as that is the only time this becomes an issue. In the case where a merge conflict occurs with the overlapping program, the second committer will notice and can report the otherwise unknown relation. But in most cases source will merge successfully without generating a conflict, as SVN will only consider it a conflict if both versions changed at the same place.
Continue reading...
Continue reading...