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 > 1.3.2.3 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. Tony