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 email@example.com.
Richard Wirth wrote: > Hello Arthur, hello Andreas, > > May be Tony has tested a different solution than provided in the patch > by Andreras? > > The patch works as follows: It's not a patch really it's a reversion to the code that was removed because it was broken (because it verifiably caused data loss). The overriding rule when considering functions in cvsnt is that it must *not* lose data. Anything that does is either fixed or removed. Convenience is very low down the list compared to that. The problem is if you merge A->B you cannot assume that A==B. Merge A->B means that B contains A (possibly changed a bit due to conflict resolitution, so B might not contain A at all in the most pathalogical case). It does not mean that A contains B. Let's go through this again. For the final time. Create file - Revision 1.1 Commit a revision to A - Revision 184.108.40.206 Make changes on A - Revision 220.127.116.11 Make changes on HEAD - Revision 1.2 Merge HEAD->A - diff(1.1:1.2)->18.104.22.168 Merge A->HEAD With one directional mergepoints: diff(1.1:22.214.171.124)->1.2 With bidirectional mergepoints: diff(126.96.36.199:188.8.131.52)->1.2 (ie. a null diff, losing the changes in 184.108.40.206 and 220.127.116.11). In the bidirectional case the revision 18.104.22.168 and 22.214.171.124 changes are lost - and that's quite a trivial example. Expand it to multiple branches and revisions and it gets hard to track. Tony