What is the reintegrate branch?

[Karl Fogel <kf...@red-bean.com>]

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@that_rev and branch@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org