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.
Thanks for the quick reply. As I understand it, then, I'm not doing anything fundamentally wrong, it's just a scenario that isn't really supported by CVS. Tony Hoyle wrote: > 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. Yes - but I don't see how that's relevant. I would contend that when I commit after the merge from HEAD to b1, I have effectively declared that b1 now contains the merged results to my satisfaction. CVS should take my word for it and regard the merge from HEAD to b1 as complete. (In fact, I may even have overridden the results of the merge with an entirely new file, if I felt like it - that's my business, not CVSs.) > Merge A->B does *not* imply a merge B->A since B will contain information > that is not in A. I agree. However, after a merge A->B, B contains a combination of information from A and information from B, and by committing the merge, I declare that I am happy with the results. At this point CVS should assume that B has all of A's information *up to the point of the merge*, and that a subsequent merge B->A only needs to take into account any changes on A and B that happened after the merge. If there were none (as my original scenario had it) then the merge is in fact simply a transfer of information from B to A - i.e., just a copy. > Some versions of cvsnt did this and it was removed after a scenario > occurred where people lost changes (luckily only minor ones). It's hard to see how changes could be lost, assuming that all files has been committed prior to the merge? Of course, if someone was so daring as to perform a merge on top of *uncommitted* changes, then they really should have known better :-) Also, as a matter of interest, do you know which versions handled the merge in the way I described? It may be helpful for us to consider looking at earlier versions, as an option for solving our problem. > Bidirectional merging is not that common - normally you merge in one > direction - eg. development->test->production, or stable->unstable. I think possibly some confusion may be arising here. I am considering a scenario where only a small subset of the files in the repository are being branched, not the whole thing - in other words, the branch is a changeset. If you are considering a branch to be a split of the entire repository then I'd agree that merging would typically be unidirectional - in the changeset scenario, however, bidirectional merges are the norm. Might it not be a good idea for CVS to support this type of branch usage through - say - another command, or another update option? Thanks again for the response. -- Tony