[cvsnt] Re: Branch merging - this seems wrong...

Tony Hoyle tony.hoyle at march-hare.com
Mon Jun 5 12:58:52 BST 2006

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.

Tony Eva wrote:
> I would *expect* this to use the mergepoints to recognise that b1
> already contains all of HEAD's changes from 1.3 to 1.5, and thus that
> HEAD 1.5 is now the common ancestor.  In fact, if HEAD has not had any
> more commits since 1.5, this "merge" should just be a trivial copy of
> across to HEAD.

It's impossible to know that - you might have discarded the merges, made new, 
conflicting ones, etc.

Merge A->B does *not* imply a merge B->A since B will contain information that 
is not in A.

Some versions of cvsnt did this and it was removed after a scenario occurred 
where people lost changes (luckily only minor ones).

> I thought this was what mergepoints were supposed to avoid?  I guess I
> can work around it by some sort of complicated tagging operation before
> and after each merge... but that's calling for a lot of manual labour
> that I expected CVSNT to handle for me.  This seems like a very basic,
> common, merge requirement - am I misunderstanding something here, or
> doing something stupid?
Bidirectional merging is not that common - normally you merge in one direction 
- eg. development->test->production, or stable->unstable.

Having two parallel branches that each need each others changes is quite unusual.


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