[cvsnt] Mergepoint issues on 2.5.0.3 b2382

Harrison, Andy andy.harrison at anite.com
Mon Jan 15 13:17:20 GMT 2007


> Basically what I believe happened was they had two independent
branches 
> of work.  Merged A->B, taking only a few changes and ignoring the
rest, 
> did some changes to B then merged B->A
> 
> What they *wanted* to happen was that only the changes they made in B 
> got merged back to A.  What actually happened was as seen in the other

> threads - it took the original mergepoint on A as a common ancestor
and 
> wiped out the differences between A and B. 

Hi Tony,

I don't want to start an argument here, I'm just trying to understand
things. Please bear with me. I realise that as the CVS team you have to
cater to all users and so changing the way the merge was done was the
best solution at the time, and may still be the best long term default
action.

As I understand the above, it's the same as the first scenario in my
previous mail. I'm interested in the changes that they did not merge.
Did they edit the file to remove the merged code? Did they do a update
-C on certain files? Or did they simply not commit certain files. It
would be my expectation that if either the second or third option were
performed, then since no commit took place on those files, no mergepoint
would have been stored. In this case on merging back to A, the branch
point would have been used as there is no merge point. Is this correct?

This leads me to assume that they must have done the first action, i.e.
merged the file and then manually edited the file in order to remove
parts (or all) of the merge. In my opinion (and I guess this is where
you disagree), these changes are edits that have been performed of
branch B, and so in merging B->A, these edits should be included in the
merge.

A similar scenario would be if the user had merged A->B and committed
all of the changes. Then they edit the files on B to remove some of the
changes made in the merge, and commit. They then merge B->A. Would you
expect those edits made between the two merges to be merged back to A or
not?

Rgds,
Andy


--
Andy Harrison - Platform Software Engineer 
Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ,
UK
"No matter how bad things seem... 
...nothing could be worse than being used as a towel rail." - A.A. Milne


A member of the Anite Group of companies. Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.  

Anite Group plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by BlackSpider MailControl.


More information about the cvsnt mailing list