> -----Original Message-----
> From: Lakshman Srilakshmanan
> [mailto:lakshman.srilakshmanan@tradingpost.com.au]
> Sent: Thursday, August 24, 2006 4:03 AM
> To: Ryan Schmidt; Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: RE: Evil twin bug ?
>
> When merging ProjectA into trunk, if we assume A1 as start of
> branch and
> A2 as the head, we will get heaps of conflicts because of the merges
> that have come from trunk. The alternative is to exclude the revisions
> that formed the merges from trunk.
That's a really bad idea. You can lose data by doing that and you will
have to recreate the merge again anyway.
When you merge from trunk to branch, you do two things:
a) make the trunk code work with the branch code.
b) make incidental changes (you add a quick bug fix into the
merge, or have to add or delete files to make the merge work, or reject
automatic merges[1])
When you merge to trunk but skip the previous merge revisions, you lose:
a)the code changes that made the trunk and branch code work
together, so you have re-fix the code (you do a very manual merge.)
b)you lose any incidental changes (the quick bug fix, added &
deleted files)
c)you have to Rely on Humans(tm) to remember all the a) and b)
changes you did on the branch (which Subversion will remember for you)
Example (pretty picture below):
branch from the trunk (branch:100 branches from trunk:99)
foo.java is changed on the branch
foo.java is changed on the trunk
merge foo.java from trunk:150 into the branch at rev 200
When you merge down to trunk but skip the merge revision, you lose the
foo.java merge changes.
svn co -r 300 trunk; cd trunk
svn merge -r 100:199 svn://branch (has the branch foo.java
change)
svn merge -r 201:250 svn://branch
The -r100:199 merge will force you to merge the branch and trunk
changes over again, which were already done and tested in 200. Which
is Duplicate Effort. Any incidental changes, adds or deletes done in
200 are also 'lost'.
100 200 250
+-*-+-----+> branch
/ ^ |
/ | V
--+---*--+-----+> trunk
99 150 300
'*' indicates that foo.java changed
Ideally, the merge should overwrite the trunk foo.java with the
branch:200 version. However, since Subversion doesn't do merge
tracking, the common ancestor is never updated, so you always wind up
with recurring merge conflicts for every merge beyond the first. The
common ancestor of foo.java is always 99 no matter how many merges
between trunk and branch are done. When the final branch to trunk merge
is done, the common ancestor really should be 150 because of the
trunk:150->branch:200 merge. (Svn really should follow merges when
determining ancestry.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 24 19:49:18 2006