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.
> Such things are often process issues, Yes, I agree. From your explanation I would say we could theoretically categorise merges. One type is a full (rebase) merge, in which every change from the source branch is merged into the target branch. The second is a partial merge in which the user selectively merges in changes. A partial merge could be done either by specifying both -j parameters, or by manually changing the results of the merge. If the user *always* does a full merge, then using mergepoints can make the merging quicker and will work in bi-directional merges. I'm assuming you agree on this point? This is what we do in our process. If the user does a partial merge by specifying both -j parameters, then mergepoints will no longer work. (This is the second scenario I referred to in a previous email.) I would suggest that if the user does specify both -j parameters then CVS should *not* store a mergepoint. (Of course there are exceptions to this were we could store a mergepoint, and these can be dealt with if desired.) Since no mergepoint is stored, this will not affect future merges. If the user manually changes the results of a merge (as in the case you describe), then we have problems. In my opinion, they have a incorrect process if they do a manual partial merge A->B and then a full merge B->A and expect the changes they made during the A->B partial merge to not be merged back again. There is no way you can expect a revision control system to be able to cope with this. If they are going to manually alter the first merge then they should expect to have to manually alter all subsequent merges between those two branches. Incidentally, I don't think this problem is confined to bi-directional merging. Consider: Branch A and B Change A1 on A Change A2 on A Change B1 on B Merge A->B but manually remove A1. B now contains B1 and A2 Change A3 on A Change B2 on B Merge A->B B now contains B1, B2, A2 and A3. If the user would expect the B->A merge to still include A1, then would they also expect it to be in a A->B merge? 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.