> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Monday, February 14, 2011 9:54 AM
> To: Varnau, Steve (Neoview)
> Cc: Daniel Becroft; users_at_subversion.apache.org
> Subject: Re: Dangerous to keep re-integrated branches alive?
> On Mon, Feb 14, 2011 at 05:41:03PM +0000, Varnau, Steve (Neoview)
> > -----Original Message-----
> > From: Stefan Sperling
> > 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?
> > > After the reintegration merge, /trunk and the branch should be bit-
> > > identical. Period.
> > No. That's not true in the general case. It's a common
> misunderstanding though.
> > See here for details: http://mail-
> > --------------
> > 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.
> > -Steve
> No, the files can differ. E.g. consider what happens if the branch modifies
> the very last line of a file. Now the branch is synced to trunk to prepare
> it for reintegration. The file receives no changes. Next, someone commits
> a change to trunk changing the very first line of the file. Then you
> perform the reintegrate merge, and it's likely that this merge is
> conflict-free (unless the file is very short). Now you commit the result
> of the reintegration merge, and the files on the branch and the trunk are
> not the same -- they differ in the first line.
Okay, but then I would not want to block that revision with a record-only merge, right? I would want to pick up that merge resolution the next time I sync-up the branch.
Received on 2011-02-14 19:06:38 CET