各位朋友，今天是香港回归11周年的纪念日也是建党节，这也标志着，2008年已经进入了7月。我们的活动，也逐渐接近尾声。
感谢各位在这次活动中的积极参与和给与流水先生以及我们SCMLife的支持！谢谢！
从今天到9日，我们将对以下2章的内容进行赏析o(∩_∩)o...


== 第七章中，讲到分支的基本策略：主线策略 ==
版本树应该长成什么样子？它应该长成钻天杨的样子，而不是长得像棵菜花儿。集中精力于主线的演进，是关于分支的最重要的策略。
还记得吗，我们在刚刚开始软件配置管理旅行的时候，谈到要建立公共的存储区，这样，大家可以有一个统一的地方，上传自己完成的工作，下载其他同志的最新进展。如果没有这样一个统一的地方，乱丢乱放乱传，就容易出问题。我们需要公共区，作为主流，向前演进。随后我们还谈到，如果不及时上传自己的工作，如果不及时下载以更新到其他同志的最新进展，也容易出问题。也就是说，与主流不要离得太远。
在讨论分支的规划的时候，需要遵循类似的原则。一个软件的研发，其主流通常就是主线。有时候我们为了某个规模不小的工作，创建一条分支。一旦工作完成，就应该停止该分支的生长，把分支上完成的工作，合并回主线。有时候我们为某个补丁版本，创建一条分支。一旦版本发布，就应该停止该分支的生长[1]，把分支上完成的Bug修复工作，合并回主线。有时候我们为了给特定客户开发某个新功能，创建一条分支。一旦工作完成，特殊版本发布给了客户，就应该停止该分支的生长，并考虑把分支上完成的工作，合并回主线。如果该新功能具有普遍意义，应该作为以后新版本的标准功能。

== 第八章中，把文档管理和代码管理做比较 ==

文档与源代码的本质区别是，源代码是人编出来给机器看的；文档是人写出来给人看的。在一个软件研发项目中，会产生各种各样的文档。这些文档以不同的形式存在。源代码文件里的注释信息，本质上就是文档，因为它是给人看的。如果注释信息比较多了，就可能剥离出来，作为单独的文本文件。这时候，就有点像是我们通常概念上的文档了。这样的文档，依然是与源代码混合在一起存放比较好，如果这样的文档与产品的某个局部紧密相关，与产品在实现上的某个细节紧密相关，如果主要是开发人员阅读它。那么，将它和源代码一同管理比较好[2]。
而我们通常所说的文档，是篇幅比较长的，格式比较复杂的，带插图的，项目、产品或组件一级的，看起来比较正式的文档，通常不仅是开发人员在读。这类文档，通常不再是一个简单文本（Plain Text）文件，而是用MS Word、MS Excel等写成的文档；这类文档，通常被单独管理，因为它们与源代码相比，有所不同。
它们与源代码的不同主要体现在两方面。首先，文档通常“文责自负”，通常有明确的所有者。一般来说，只有他会改动该文件。不同的人同时改一个文件的可能性不大。一起修改一份文档的情况是如此明显，以至于通常在事情发生前就协调开了。事实上，如果两个人同时修改同一个文档，那么将来合并时，通常会有一定的技术困难和时间上的不少耗费。因此，对文档修改的协调，通常是用锁机制，或者干脆就不提供自动机制。
其次，文档通常“独立成篇”，文档之间相对独立。为某个原因修改源代码的时候，常常需要修改几个相关的源文件，然后一同编译、链接。而为某个原因修改文档的时候，常常是只需要修改一个文档。在修改之后，也不存在一起编译之类的问题。因此，为获得整体环境而创建工作空间，意义就不大。用任务单元来标识对多个文件的修改，意义也不大[3]。文档如此独立，阅读者如此广泛，以至于经常被通过各种途径传播，比如Email等。因此，文档自己说明自己的能力，就变得重要[4]。这是下一节的主题。

[1] 这里说的不是绝对的，只是原则。原则是：让分支尽量短。

[2]        需要与源代码保持紧密一致的文档，也值得考虑与源代码一同存放，一同管理。典型的例子是用户使用说明文档。当然，也有其他一些手段，用以保证文档与源代码的一致性。

[3]        尽管文档之间相对独立，有的时候，标识几个文档文件的整体版本，仍然是有意义有价值的。甚至，标识文档与源程序之间的版本跟踪关系，也是有意义有价值的。

[4]        事情是相辅相成的。由于文档通常具有自我描述的能力，并且文档通常有明确的所有者，因此对它可以管得比较松，允许通过E-mail等方式传播，而非一定要从版本控制工具里取得。

关于分支的基本策略：主线策略；
个人的感触是有一个类比：
一种是“在忙着追求自己梦想的同时；别忘了顾好当前脚下的路”；
一种是“在匆匆忙忙走着脚下的路的同时；别忘了追逐自己的梦想”；
当然；
主线策略是确定唯一的；
我这里的类比不知道大家是否也想唯一呢？

关于文档管理；
其实也是相当重要的；
文中开始把文档管理与源代码管理结合起来进行比较；
也强调了文档管理的重要性；
感觉文档管理是一个大头戏；
离开编码也好久日子了，
整天和文档打交道；
不想重视都难啊。
只是还有好多方法需要学习。

这段太晦涩了，没什么感想了

引用:

原帖由 missdeer 于 2008-7-4 19:35 发表
这段太晦涩了，没什么感想了

呵呵，都节选到第8章了，也难怪接不上了。

还没有动心买书啊？

引用:

原帖由 流水先生 于 2008-7-7 21:53 发表
呵呵，都节选到第8章了，也难怪接不上了。
还没有动心买书啊？

在公司翻过一遍了～
书非借不能读也
其实我自己是做开发类工作的，对SCM方面的技能要求并不高，懂得一些基本的规则和工具使用方法即可满足日常工作需要。只不过平常跟一群做SCM的同事玩得比较好，爱屋及屋对这方面就稍有点兴趣，有所关注～

[ 本帖最后由 missdeer 于 2008-7-7 22:32 编辑 ]