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.
Tony Hoyle wrote: > But you have not said that b1 contains HEAD - in fact they > may be very different. When I gave the command 'cvs -j HEAD c.c' to merge HEAD to b1, I said to CVS that b1 will now contain HEAD. That's what a merge is, surely - the incorporation of the information from one branch into another. Indeed, that's what mergepoints are for: explicitly to recognise the fact that once a merge has taken place, that merge must not be repeated because the information has now been included in the merge recipient. > It doesn't - it needs to take into account all changes in B > that happened *before* the merge too. The result of the merge is a file (on B) that has all of B's changes up to the merge, and all of A's changes from the branch point up to the merge. Assuming no other changes on A or B, a merge from B->A is just a copy because all of the information from A and B are in the head of B. There is no other information that isn't there. > If you [do] bidirectional merges you don't have a proper > changeset since you haven't clearly separated the changes. Maybe 'changeset' was the wrong term, and maybe also we're running into confliciting views about how we anticipate that CVS would be used. This is how I see it: If a developer is responsible for implementing a feature of some complexity, the coding/testing may take some time. It would be reasonable for them to want to save their intermediate work into the repository from time to time, to guard against accidental loss of their working copy; so they would wish to perform occasional commits of unstable (or even non-functional) code. They cannot commit this to a stable HEAD, and so will instead create a private branch and commit to that. Since the feature takes some time to code and test, HEAD will move on, and they will wish to keep their private branch up to date with regular merges from it. Finally, they will make the last couple of changes, do a final merge from HEAD to pick up the last few updates, run their last test, and then commit for the last time to their private branch. Now the feature is complete and stable, it can be included into HEAD. That's where the "bidirectional" merge comes in (and, in my view, comes unstuck). > Normally this wouldn't be handled by branches at all - you'd > do it using the builtin support using bug IDs or by either > cooperative or reserved edits. I may well be trying to use branches for something other than their intended purpose, and maybe bugids will do what I want. I will look into that in more detail. However CVS *does* support the ability to put individual files on a branch, not the whole repository, and it is a legitimate use of the branching capability (IMHO) to allow a set of files to be collected together as I outlined. I still believe that the CVSNT behaviour under the bi-directional merge scenario is counter-intuitive, and I struggle to see how it can be regarded as correct. Sorry if I'm banging on about this too much, and I appreciate the responses so far - I am just having some difficulty working out if it's possible to use CVS to support the development model I need. If not, so be it, though I can't see that what I'm proposing is particularly weird, so I feel there must be a way of doing it. -- Tony