mercurial case study 1

相关：http://tieba.baidu.com/p/2572785363

根据你的描述，我理解为:
1. master 属於 release tree，其中每个 rev 都确保 functioning
2. 使用手工编排序列号，以图方便引用
而这个和我的猜测一致，所以才有这贴
这个 checkin local branch as many time as you wish, rewrite history (to make it good, linear, whatever) before publish, 就是为了满足第一个要求。这个是个流程和实际 rev 内容无关，不管是 add new feature （这裏的例子）还是 next iteration（你的描述）。
重要的 release，应该用 tag
2. 就是我想详细说的，问题很大的一点，如果你编排的序列号仅仅出现在 change log，那还只算给作者本人增添麻烦而已，但像现在每次 changeset 都包含改动多个文件，而这些文件仅仅是修改你手工编排的序列号和日期，那麼就是人为的增减了障碍和噪音：
1. 每个 changeset 的 diff 多了很多和真正改动无关的内容，这是人为噪音
2. 每个 changeset 的 message 只有一个无甚意义的序列号，这是人为噪音
3. 每个被改动的文件，都必须重新 compile，又编译慢的 c++，这是人为障碍
4. 每个 changeset 都因为这些无关的文件被改动，而必须多次 IO 操作，这可能也是你的情况 pull/push 慢的原因之一，这是人为障碍
rcs/cvs/svn 可以在源码中内嵌序列号，那是因为它们 checkin 的只是 placeholder，checkout 时自动替换的，并不会为 diff 增加噪音。而 dvcs 不同，历史为 DAG，理论上不能保证线性历史，所以序列号意义不大。hg 也有插件做这个，但基本没人用。另外，例如 rev 2104 真的比 rev 502cf632 有意义又好记这麼多麼，在我看来都一样。
如果你想要每个 build 都带有具体的 rev，自动生成即可，例如在 make 的 build target 裏加上一行比如 echo 'const char* ="'$(hg id -i)'";' > version.h
其他源码 include 即可
要保证 master 裏每个 rev 都 work，你需要的是一个合理的流程，或简单的 push hook 或者某种 continuous integration 的套件
要容易跟踪改动，那麼就减少每个 changeset 的噪音，特别是每次 rev 无意义的序列号和日期，这些讯息都能从 changeset 得到，没有任何理由需要在内容裏再重复

增加的麻烦还有很多的，上面编辑的时候忘了，比如
正常使用方法时，我可以通过 message 快速找到那个功能在那个 rev，或者那些 rev 改动过某个文件，这些都可以一行命令就做到，而且不需要查 diff
这是你昨天提到的两个使用情况
而目前的做法，只好找个效率高点的 GUI，人肉每个 diff，因为 changeset 中信息不足而噪音太多，和人肉没什麼区别

写有意义的 message，不仅仅让查找方便，比如，hg 可以这样生成漂亮的 ChangeLog:
hg log --style changelog