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

Re: Dangerous to keep re-integrated branches alive?

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Sat, 12 Feb 2011 16:08:26 +1000

On Sat, Feb 12, 2011 at 1:10 PM, Varnau, Steve (Neoview) <
steve.varnau_at_hp.com> wrote:

> 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).

My understanding is that this should never happen. During a reintegration
merge, there is validation that all revisions from the target (normally
/trunk) have been merged across into the branch - any conflict resolution is
done during this merge. The reintegration merge then does a basic file
compare, and merges across.

After the reintegration merge, /trunk and the branch should be bit-by-bit
identical. Period. If not, then either your use case for merging is a little
strange, or there is a problem.

Daniel B.
Received on 2011-02-12 07:09:27 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.