Peter Valdemar Mørch <email@example.com> wrote:
> haller-at-ableton.com (Stefan Haller) |Lists| wrote:
> > No, this is wrong. It will often work, because Subversion notices that
> > the trunk you're merging into already contains most of the changes you
> > are trying to merge into it; but it doesn't always work, and it is not
> > the correct way to do it.
> What is wrong about this? In what situations won't it work, what is
> "incorrect" about it?
It will cause conflicts, and it my experience there can easily be so
many conflicts that resolving them is infeasible (too error-prone).
But you are right, conflicts is the worst you will get (i.e. you will
never get an incorrect merge result without having a chance to notice),
so you can always try this first, and if you get conflicts, revert and
use the "clean" way instead. Personally, I'd always do the clean merge
right away, though.
> > Instead, merge the differences between trunk@150 and branch@HEAD into
> > the trunk. You need to be very careful that the branch really contains
> > all the changes from trunk up to r150, otherwise you will revert the
> > ones that it doesn't contain.
> Yikes! Loosing changes to the trunk is the absolute last thing that must
> ever happen. "You need to be very careful that the branch really
> contains all the changes from trunk up to r150" How does one *ensure*
> that if there 1047 changes/revisions on the trunk in that period, so
> that manual checking is unfeasable/impossible?
Simply make sure that the merges from the trunk to your branch were
contiguous. This is not too hard if you write good log messages. For
example, you create the branch at r135; a week later you merge r135:247
from trunk to your branch; another week later you merge r247:317 to your
branch, and so on. At the end, you merge the differences between
trunk@317 and branch@HEAD to the trunk. It is really not so hard to
keep track of what you merged, if you work carefully.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Nov 1 20:51:21 2004