mercurial case study 1

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

solo可行。不过不适合我的需求。
首先，master会被作为重量级的branch而不是bookmark，是因为它是预期表示真正分支而不是具体rev的一种公开的接口约定，应该影响所有repo副本的历史结构。而bookmark默认不会被push，表示的是rev。
其次，关于publish的内容区别。这里，人为附加的主分支版本版本号作为线性版本序列的标识，也是一种公开接口（相比于正式发布的版本号只是最终用户不需要关心而已），是需要出现在版本库中的。出现在提交信息中是最简便的做法。
关于提交信息，其实这里是有意不写实际修订内容，因为master branch rev不是在内容上有单一确定目的的修改而是一种有计划的“事务”，其中具体内容并非保证是单一修改的序列，内部可能还有依赖关系（如果全部publish来体现这里的依赖又过于琐碎），在提交信息里要写完整通常更乱。（具体正式changlog的形式由项目决定。）

根据你的描述，我理解为:
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

8pm赶紧码一个用到了再看！