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.
Arthur Barrett wrote: >> I think it only works if the bugid commits never contain any code that >> has been merged in from a branch to which you merge that bugid code >> later. > > Err yes - my example was backwards. So when you make "real" changes to > the branch then you use unique bug ids, and you then merge those bug > id's down to the trunk, which obviously don't exist there... But that is > potentially more than just a single merge, since there may be 20 or 30 > or any number of them... An example, maybe. Talking about firmware for an embedded processor. The board gets an upgrade, some features of the board change and need firmware to be adapted. The firmware for the new board is developed on a branch off the test branch. These changes are for the most part well-contained, but still affect a lot of code. Some are not so well contained. The whole change is a single bugid; there is not much point or even possibility to separate it into 20 or 30 bugids, as all changes depend on each other (and the new board) and can't be merged separately anyway. While the new board goes through testing and pilot production runs and the associated firmware debugging, the firmware for the old board continues to be developed with new features and other changes like bug fixes being merged to the test branch. In order to keep the firmware on the new-board-branch close to the firmware that's actually in use, the code from the test branch (parent of the new-board-branch) is regularly merged into the new-board-branch, using single j merges to simply stay at the tip of that branch. This all works very nicely with the tools CVSNT (and the various GUIs) provide, and it seems it's something it was designed for. Now when the new board has been tested sufficiently, it is put into production. At this point, the new-board-branch has to be merged into the test branch; I don't see any other way. And since the changes on that branch contain code that was merged in from the test branch (whether you used a bugid for all commits on it or not), it seems that the best (least conflicts) way to do this is Tony's double j merge. Using a single j bugid merge would result in numerous conflicts; in this case it would be the same as a simple single j merge (because all commits on the new-board-branch belong to the same bugid). (Before we go off on a tangent: I think the whole scenario doesn't change at all if we branch the new-board-branch off a development branch, a test branch or a production branch or any other branch. The only thing that is important is that this branch changes during the development on new-board-branch, and that you want these changes in your work on the new-board-branch. Not necessarily always immediately, but still.) > Back when this was frist described I had never heard of it being needed, > and I still am in the same boat. It is how I usually work and many others I have talked to also seem to work like this. > If a bug is found on the branch that is applicable to the trunk then that > bug is applied down to the trunk at the time (either by merge -j branch > -B bug or by recoding), not some arbitrary point later... Of course, but that's not my point. > But I understand you are describing a process that works for you - I > can't help myself suspecting that if changesets were used more then a > change a little here and a little there to the process and most of this > "problem" would go away. I would be very interested to hear where I'm making things more complicated than needed -- if that can be shown easily. > Suggesting a double j mergepoint for EVS now we have all the details > makes sense I think, but I still remain sceptical that you'd really do > things that way if you were using changesets... Or if not maybe > changesets need to support this process better... Maybe the latter. I don't (yet) see how bugids simplify the issue with bidirectional merge, or how it can be avoided in such situations of parallel development of orthogonal features. One loosely related feature I'm dreaming about is that the system knows what has been merged and excludes anything that has already been merged from a future merge (unless an override option is set that advises it to merge "literally"), for both unidirectional and bidirectional cases. Gerhard