[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Tue Sep 11 18:22:06 BST 2007

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.


More information about the evs mailing list