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