Hi there, I'm looking for a best practice for the following situation: We have several long-living product branches forked off a common trunk. They cannot closely follow trunk, that is, merging often from trunk is not an option.
Bugfixes and some features need to be backported to trunk, though. Which is, as I have learned recently, not explicitly supported by Subversion. (Developing those bugfixes and/or features in trunk is also not an option for various reasons.) After reading several articles and discussions I came to the conclusion that the best practice would be to svn merge --ignore-ancestry from child to trunk, while manually selecting the changes (e.g. by revision) we want in trunk. That is, these "merges" need to be tracked manually. If we provide some helper scripts, the revision resulting from that merge could be --record-only merged back to the child so we won't get conflicts later. Correct? Now, if a major product version goes EOL, we could simply create a "reintegration branch" from it's main branch to perform the trunk->child merge there and use --reintegrate afterwards to get all not-yet-integrated changes back to trunk, right? (The extra branch is used so the product's main branch won't get disturbed and is still available for bugfixing etc. While I'm thinking about it - would it be possible to always keep that branch and it gets changes from trunk and the product's main branch from time to time so we can reintegrate the product's current state into trunk more often?) To rephrase that question, is it okay to have these branches: /trunk /prodA /prodA/reintegration and to integrate changes in /prodA to trunk without merging from trunk first, do merge /prodA -> /prodA/reintegration, then do merge /trunk -> /prodA/reintegration, then reintegrate-merge /prodA/reintegration to /trunk? Would Subversion handle that or problems ahead? Thanks for any input, Tino. -- "What we nourish flourishes." - "Was wir nähren erblüht." www.tisc.de