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
Received on 2011-03-09 19:35:17 CET