[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: Varnau, Steve (Neoview) <steve.varnau_at_hp.com>
Date: Mon, 14 Feb 2011 17:41:03 +0000

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Saturday, February 12, 2011 5:10 AM
To: Daniel Becroft
Cc: Varnau, Steve (Neoview); users_at_subversion.apache.org
Subject: Re: Dangerous to keep re-integrated branches alive?

On Sat, Feb 12, 2011 at 04:08:26PM +1000, Daniel Becroft wrote:
> 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).

I would say that depends on the kind of conflict resolution.

Maybe you're resolving a conflict in a way that is specific to trunk
and must never go to the branch (i.e. you will keep the conflicting
piece of code for a while and resolve it later). In that case, it's
correct that the revision is blocked from being merged into the branch.

Else, you should require that the reintegrate merge is conflict-free.
So if you run into the situation where another commit to trunk sneaks
in after you sync but before you reintegrate, you simply sync again
and then try to reintegrate again.

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

It can happen if someone commits to trunk after you sync the branch
to trunk but before you reintegrate it.
> After the reintegration merge, /trunk and the branch should be bit-by-bit
> identical. Period.

No. That's not true in the general case. It's a common misunderstanding though.
See here for details: http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3C20100929200923.GC7378@ted.stsp.name%3E

Thanks for both replies. So, at least one could do a double-check if the files involved in the re-integration check-in revision are identical on the branch. They should be, and if so, then it is safe to block the merge and keep the branch alive.

Received on 2011-02-14 18:42:18 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.