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: > That's what you have the development branches for - > developers should be working on that not the testing/stable > branches (in fact in that scenario there would *never* be a > commit directly to a stable branch). Umm... I think we have a failure to communicate here, because that's what I said (or thought I said). However, we do seem to agree that the developers work on a development branch (perhaps several development branches). Let us assume that the intention is for the work that is done on the development branch to be added to the stable branch when it (the development branch) is tested and stable. That means there must be at least one merge from the development branch back to the stable branch, not so? Otherwise the development will never be included in the stable build. So, if that is the case, then what happens if the development is significantly complex and takes a long time, and while it is taking place, other developers are merging from their completed development branches to the stable branch? It's reasonable to assume that our developer will want to include their stable code in his development branch so that he is working with an up-to-date stable baseline, and so that he doesn't get left with an horrendous merge at the end. So it is fair to postulate a series of merges from the stable branch to the development branch, culminating in one merge back from the development branch to the stable branch at the end. This is the scenario that CVS does not seem to handle - specifically, the one final merge back to the stable branch, where in my view the ancestor (or merge base point) is incorrectly determined. > Once you branch it's a separate line of development - > branches are there precisely for when you do *not* want to > track the commits on the trunk. No, I don't see what you mean here. You seem to be saying that a branch, once made, is kept in isolation from the trunk (or stable code branch - whatever you prefer to call it). If that's true, then why bother with merges at all? Are you saying that once a branch is created, only one merge can be contemplated: back to the stable branch? That would seem to be a huge restriction that only allows CVSNT to support one specific code development process, and makes it very hard to keep separated development streams in sync. > It's the only reasonable behaviour. There's no automatic > way to do this and absolutely never can be since it's an > unsolvable problem. We'll have to agree to disagree on this point, then. I simply don't see what's insoluble or even difficult about it, so I have to conclude that we are simply misunderstanding each other's point of view. Yes, there are intractable merge problems, but I don't see that this is one of them. -- Tony