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

What is the reintegrate branch?

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 10 Jan 2008 17:00:04 -0800

I thought this bit of IRC conversation might be useful for others
here, as it explains at a very high level what the reintegrate branch
is all about.

The question of how to *reach* this algorithm -- whether via option,
or auto-guessed, or what-have-you -- is separate, and I don't want to
get into it in this thread. This post is just to clarify what the
algorithm does and why it's useful; no need to follow up unless
there's something absolutely burning up inside you :-).

<kfogel> lgo: the original thinking behind --reintegrate might be
          illuminating here.

<kfogel> It started out with this observation:

<glasser> I mean, I think they're the same in the super trivial case
          of "create branch from trunk, do some work, never merge
          either direction, then merge back to trunk"

<kfogel> If you have a branch from trunk, and the branch is
          *totally* up-to-date w.r.t. trunk, then merging the branch
          back to trunk can be done in one of two equivalent ways:
          take all the branch changes and apply them to trunk in order
          (takes longer, less efficient, etc), OR you can just replace
          trunk's tip with branch's tip :-).

<lgo> k

<kfogel> Now, some more cases become possible: if you can find a
          revision of trunk w.r.t. which branch is fully up-to-date,
          even if it's not the most recent rev, then you can just diff
          between trunk_at_that_rev and branch_at_tip, and apply that single
          diff to trunk and get the right result.

<lgo> k2

<kfogel> (I think there may be more, but I can't spin 'em off the top
          of my head right now.)

<kfogel> Anyway, the point is:

<kfogel> These are very common cases, and in fact, where they are
          *not* common, it is even sometimes the case that the user
          would like to be told that the branch is not up-to-date or
          something and fix that problem before merging.

<kfogel> So rather than viewing every merge as an opportunity for a
          setwise-complete cherry-picking festival, we win by viewing
          some merges in terms of their larger semantics.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-10 23:00:33 CET

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