John Schulz wrote:
> I was just reading Common Use-Cases for Merging in the Subversion
> book <http://svnbook.red-bean.com/en/1.1/ch04s04.html>, and had a
> question about the procedure.
>
> It says the faulty process of comparing the HEAD of the trunk with
> the HEAD your branch is bad because: "it would not only show the
> addition of your branch changes, but also the removal of trunk
> changes that never happened on your branch."
>
> What struck me was "removal of trunk changes that never happened on
> your branch." Because of that, I was expecting (1) an instruction to
> "make sure your branch is up-to-date with trunk changes", or
> something similar, or (2) the first step in the merge to incorporate
> the latest trunk changes into the branch, as covered in Copying
> Specific Changes.
>
> Is my assumption correct?
In some cases, yes; in most others, no.
Consider the case where a security fix has been made in the trunk, and
it has to be applied to not only the feature-development branches, but
the "production" bug-and-security-fixes-ONLY branches. You specifically
don't want to apply *all* changes to the trunk to one of those
feature-frozen branches, but you certainly want to apply the security
fix!
In the case of a new-feature branch, all you need to know are what
changes you've made to the files to add the new feature. It's probably
(fractionally) simpler to just merge those changes back to the trunk,
rather than merging trunk development into your branch, then merging
everything back to the trunk. On a longer development cycle, you may
end up merging from the trunk into your branch to make sure you don't
wander too far from the trunk (IIRC this is mentioned in the book).
In general terms, I would personally recommend NEVER trying to compare
trunk with a branch unless that's what you are really looking to do;
always compare a branch's HEAD with an earlier revision of that branch,
or trunk's HEAD with an earlier revision of the trunk.
-kgd
--
Get your mouse off of there! You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 31 19:18:12 2004