Hi Reedick,
I agree with everything you said, but will like to make just a couple of
comments.
> 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.
I do agree that it will be a duplicate effort, but any merge will
require a full test before moving forward, besides the merge is done by
a tool, so there is little effort form us.
> Any incidental changes, adds or deletes done in
> 200 are also 'lost'.
I have established a process that all changes (as a result of a merge)
must be committed before any incidental changes are done. This avoids
the problem you identified.
Thanks
Lakshman
> -----Original Message-----
> From: Reedick, Andrew [mailto:Andrew.Reedick@bellsouth.com]
> Sent: Friday, 25 August 2006 3:47 AM
> To: Lakshman Srilakshmanan
> Cc: users@subversion.tigris.org
> Subject: RE: Evil twin bug ?
>
> > -----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 Fri Aug 25 03:13:40 2006