[cvsnt] Mergepoint issues on 2.5.0.3 b2382

Gerhard Fiedler lists at connectionbrazil.com
Sat Jan 13 11:46:44 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.


Andreas Krey wrote:

>> If in the merge A->B you had discarded some/most changes as being 
>> irrelevant, committed, then done some more work on branch B then the 
>> merge back must not use 1.2 since 1.2 is not the logical ancestor
> 
> True. But when you don't actually bring in everything from 1.2 then
> there should not be a merge arrow for that action in the first place.

That depends. Maybe the same functionality has been added differently on
the branch and on the trunk. (Say both code lines needed to buffer/queue
some event that previously was handled directly, for different reasons.)
Obviously when you merge the code, you throw away one of the two
implementations (or both, and create an equivalent third).

Merging (as I see it) is not "putting every code that's in both code lines
into one", it's "making the code do everything that's done in both code
lines, in a way that makes sense in the light of the changes in both code
lines". Which may result in substantial code changes in one or both code
lines during the merge.


In any case, there seem to be scenarios where merging back-and-forth isn't
safe; the disagreement is which these are exactly. There is a solution
(unidirectional merge, with a branch copy at the end) that provides all the
benefits without the dangers of running such back-and-forth merges. I fail
to see the actual problem :)

Gerhard


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