[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Dangerous to keep re-integrated branches alive?

From: Varnau, Steve (Neoview) <steve.varnau_at_hp.com>
Date: Sat, 12 Feb 2011 03:10:25 +0000

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.

Received on 2011-02-12 04:13:24 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.