Dangerous to keep re-integrated branches alive?

Hi all,

My development group uses quite a bit of branching. I'm trying to train folks to delete a task branch once it is integrated and create a new one for the next task. Of course the svnbook gives the recipe for "Keeping a reintegrated branch alive", by using a record-only merge to block the integrated revision from being merged back to the task branch later on. (when sync-ing up the branch)

It has always seemed to me that that is risky. If there were changes in the re-integration merge for conflict resolution, etc, then those changes are also being blocked from being merged back to the (kept-alive) task branch. Future changes on the task branch don't include those fixes and future re-integrations could potentially even over-write them (since the mergeinfo data says we're all up-to-date with respect to that prior revision).

I hope that description is not too abstract. Am I worrying about a non-existent problem, or is there really potential to drop a change that should have gotten merged forward?

I know we can always go back in history and find the change, but I'd rather set up our branch/merge process to be as correct as possible and not rely on testing to find that we dropped bit of code.

TIA,
-Steve
Received on 2011-02-12 04:13:24 CET