The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Friday, October 12, 2012

Closing and merging branches

I like developing on branches.  Task branches usually, short and sweet, merged back into the parent main line of development as soon as possible.  Sometimes longer lived "line of development" branches, merging to and from the mainline.  Named branches if I have had foresight, although Mercurial's anonymous branches are not so bad, although they can be misleading.  (Wanted: retroactive renaming of branches.)

Just now closing a doubly nested task branch, merging into its parent line of development branch, and merging that into the default trunk.

Straightforward.  But annoying in that I have to run tests at each stage of the merge. (Actually, I feel that I should run such tests - the project is not so well disciplined.)  Plus check in three times: once for the last change in the task branch, once in the LOD branch, and once in the default trunk. With three separate checkin messages.

Some of this testing is unnecessary.  E.g.

      hg update -r LOD

      // close and merge task branch into LOD branch
      hg merge -r task-branch
      make -j test
      hg merge -r default
      // LOD changes, but no changes wrt default. i.e. no LOD changes during task branch life.
     make -j test <--- unnecessary, because tested on task branch
     hg ci -m 'merged task branch'
     // merge from mainline before pushing back
     hg merge -r default
     // no changes.
     make -j test <--- unnecessary
     hg ci 'updated LOD branch from default trunk main line of development'

     // merge back into trunk
     hg update -r default
     hg merge -r LOD
     // many changes wret default, but no changes wrt LOD
     make -j test <--- unnecessary, since file contents same as LOD
     hg ci 'updated default trunk main line of development from LOD branch ...  need more description'

i.e. it is good to know when there have been no changes in the actual file contents wrt one of the parents.

unnecessary tests could be eliminated.

(unless, of course, the tests do stuff specific to whatever branch the workspace is on. Which we actually have a minor example of. :-( )


similarly for checkin messages:

we have the convention of having branch merge messages summarize everything done on the branch.

So above I end up writing almost the same checkin message twice.  Which is more hassle than it sounds.

No comments: