We're running with the following branching strategy, with svn 1.6.12 server & 1.6.x clients (my client is 1.6.12, not sure about exact version of other developers):
Trunk mirrors production, and is always stable. No commits ever go directly to trunk, only merges. All merges take place at the top level branch/trunk directory. Off of trunk was branched release1, where work for release1 was done, and then reintegrated back into trunk and archived away/ignored. Before release1 was finished, release2 was branched off release1. Once release2 was released, it was reintegrated back into trunk. release3 branched off release2, etc.... Changes from releaseN are continually merged into releaseN+1. Emergency patch/fixes are committed to the lowest non-reintegrated release and then cherry picked/merged into trunk when needed. For more invasive changes, feature branches are created from the "current" release, and them merged back to the "current" release when ready. These feature branches are continually kept up to date by merging from the "current" release. This all works great for the most part, except when the "current" release changes during development of a feature branch. Sometimes everything seems to work fine, but have recently been running into issues with the "upgrade" merge from releaseN to releaseN+1. Issues being tree conflicts + apparently spurious file conflicts. An example: 1) create a branch off release10 2) merge release10 into new branch after a number of release10 commits 3) merge release10 into release11 4) try to "upgrade" new branch by merging release11 into new branch -- get conflicts even without having made any changes on the new branch yet. History of an example file that got a tree conflict: release10 svn log: r40635: create file release11 svn log: r40635: create file (this is the release10 commit) r40671: svn merge release10 release11 (merge of r40630 through r40670) History of an example file that got a regular conflict: release 10 svn log: r40553: create file r40605: modify file release 11 svn log: r40553: create file (this is the release 10 commit) r40581: svn merge release10 release11 (merge of r40489 through r40580 -- includes the creation only) r40630: svn merge release10 release11 (merge of r40581 through r40629 -- includes the modification) Any explanation as to exactly what's happening here? Should this general strategy be working? if so: -what are we doing wrong that is causing the conflict issues? if not: -what change to our strategy would be compatible with long running feature branches? -why does the "upgrade" merge sometimes work? (the branch i'm having trouble with now started off release7, and got up through release9 without problem, but running into lots of issues upgrading it to release10) -is there any way to salvage such a feature branch short of creating a new one off the latest release and manually reapplying all the branch changes to that new branch? Thanks for any light you can shed, -Joe
