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