[cvsnt] Mergepoint issues on 220.127.116.11 b2382
andy.harrison at anite.com
Mon Jan 15 14:47:04 GMT 2007
> 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
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
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?
Andy Harrison - Platform Software Engineer
Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ,
"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