Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
On Fri, 12 Jan 2007 16:22:18 +0000, Tony Hoyle wrote: > Andreas Krey wrote: > > > This is not what the patch does, obviously. It chooses the diff from > > 1.2 to 184.108.40.206 to be merged into the head. You need to used the base > > of the last merge arrow as the base version for the merge, not the tip. > > But 1.2 is *not* an ancestor of 220.127.116.11, It has become one by inserting the merge arrow. 18.104.22.168 contains the changes made in 1.2 as well as the head, so it is effectively the ancestor. Merge arrows are no thinner than the other lines in the revision graph. You need to follow both to find out into which revisions the change of a given revision has been propagated. > so the merge is bogus. But it happens to yield the correct result. And that is not a coincidence. Effectively, by the merge into the branch, you are pruning away the path via 22.214.171.124 and 126.96.36.199 and leaving 1.2 as the new common ancestor. > All you've done is degraded merge into a simple copy. That is only because I did not modify the head before the backmerge. If I did, that would have been a regular merge with possibility of conflicts. > In a true merging > situation the two branches can easily follow independent paths and never > be identical to each other - mergepoints are designed to help you > extract the difference between two points on the *same* branch. Nope. They are designed to avoid the manual bookkeeping necessary with plain cvs. Says so on the aforementioned cvsnt wiki page. > What you seem to want is not mergepoints but a copy operation. Nope. Even when the backmerge degrades into a copy because nobody else worked the head in between, the recorded merge arrow allows to continue working in the same branch. If I would copy around cvs (and not leave the merge arrow) the next merge into the branch would go bad as well. Andreas Reference: 1.1---------+ | | | 188.8.131.52 | | 1.2 184.108.40.206 | | +-----> 220.127.116.11 | | 1.3 <-------+ | | -- np: 4'33