[cvsnt] Mergepoint issues on 2.5.0.3 b2382

Tony Hoyle tony.hoyle at march-hare.local
Fri Jan 12 14:23:12 GMT 2007


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 sales@march-hare.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 1.1.2.1
Make changes on A - Revision 1.1.2.2
Make changes on HEAD - Revision 1.2
Merge HEAD->A - diff(1.1:1.2)->1.1.2.3
Merge A->HEAD

With one directional mergepoints:
diff(1.1:1.1.2.3)->1.2
With bidirectional mergepoints:
diff(1.1.2.3:1.1.2.3)->1.2 (ie. a null diff, losing the changes in 
1.1.2.1 and 1.1.2.2).

In the bidirectional case the revision 1.1.2.1 and 1.1.2.2 changes are 
lost - and that's quite a trivial example.  Expand it to multiple 
branches and revisions and it gets hard to track.

Tony


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook