Rewriting history can be good (esp checkin messages)

It can be good to be able to rewrite history.

Or at least checkin messages - or, rather the text associated with a version.

Checkin messages are really what was entered at checkin time.  But if these are rewritten, may warrant a different name.


Writing good checkin messages can be hard.  Sometimes I hesitate to merge my changes because it will take too much time to write a good message - especially given our local rule of having a branch merge summarize all changes on the branch.  But slow to integrate is bad.   Or I write a sub-par checkin message.  But that is also bad.

Better to merge, integrate asap, with whatever you can say at that time.  And, if necessary, go back and rewrite the messages to improve them.

It's like refactoring.

LOD branches (Lines of Development)

Not sure if this is a Glewism, although Brad Appleton's book undoubtedly similar.

A LOD branch is not like a task branch.  A task brach ideally exists only briefly.

A LOD branch is long lived.  It may be periodically synchronized with other OD branches, and/or the mainline of development.  Bidirectionally synchronized - changes may be pushed and pulled.

For long periods of time a LOD branch may be collapsed - basically part of the main line of development.  But it may be revived as a separate LOD branch.


Examples of LOD branches:

* branches for different platforms, where there is not a single source tree with ifdeffing or other conditionals

* maintenance branches for old major releases

* branches where you are working on a new experimental feature or system

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.