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
Received on 2011-07-24 15:38:08 CEST