This approach ultimately forces them to delete and re-create /trunk as a branch of /branches/QA so merging can still take place! Obviously this leaves a big “discontinuity” in the history, and makes many repository maintenance and conversion tools break horribly. I’ve also seen developers delete /branches/QA entirely and re-branch it from /branches/DEVELOPMENT. This seems to work intially, but generates more merge conflicts in the future, because the relationship between certain files in the two branches is lost, and ultimately doesn’t really fix anything. Over the years, I have seen developers pull out file comparison tools and “manually” do this, which actually causes a gap in the internal Subversion history as renamed files “appear” in the history instead of being copied from /branches/DEVELOPMENT. The only real solution is to periodically “catch up” /branches/QA to /branches/DEVELOPMENT somehow.
Subversion conflict resolution manual#
The branches have basically “diverged” significantly due to code being merged out-of-order and doing manual conflict resolution.
You often get into a case where almost every merge from /branches/DEVELOPMENT to /branches/QA generates multiple conflicts of one form or another. Now if you have dozens of developers working on the same application, with features and bug-fixes being committed to /branches/DEVELOPMENT every few minutes, problems escalate rather quickly. If some files or folders were refactored or renamed in /branches/DEVELOPMENT, and the “later” bug-fix commit has a dependency on that rename, you have to do some manual conflict resolution to get things to merge into /branches/QA in a working fashion. This “cherry picking” of code can be problematic in almost any version control system (including Git), but in Subversion it can result in merge conflicts or even the dreaded tree conflict because you are pulling in issues out of order. That is, sometimes you have a bug-fix that you want to move rapidly into production, so it gets plucked from /branches/DEVELOPMENT by itself without merging some of the commits that came before it. Now, what frequently happens in this situation is issues are merged from /branches/DEVELOPMENT to /branches/QA out of order. So your bog-standard SVN repository would look something like this: /trunk From there code is merged into a QA branch for further testing, and is eventually merged into trunk and released. All your development is done in “feature branches”, which you merge into a “development integration” branch.
Let’s say your development team is following the common pattern for maintaining a “clean” releasable trunk in Subversion. Forcing a correct Subversion branch merge despite tree conflicts
0 kommentar(er)
