随着现在液晶显示器分辨率越来越高，大部分的网页无法充分利用显示器的整个屏幕，Firefox3和IE7+都有整页缩放的功能，可以弥补这个缺陷。使用整页缩放将原网页放大到130%或者更高，可以让网页浏览变得更加轻松。但是细心的使用者会发现，IE8进行整页缩放后浏览器基本处于假死状态，而Firefox3则和没有缩放的时候速度没有区别。

1. 内存占用和浏览速度，在我的CM1.3G、768M内存的机器上，IE 7 经常失去响应。Firefox 从不。
2. 丰富的插件，鼠标手势、Drag2Go、增强TAB浏览、AdBlock、天气预报……数不胜数
   
3. 丰富的皮肤，与一成不变的IE相比，Firefox可以更加个性化
   

1. ThunderBird 具有同Firefox一样强悍的可扩展能力和易用性。
2. ThunderBird 借助于lightning和Provider for google calendar两个插件，可以同步Google日历。
3. ThunderBird 借助于Contacts插件，可以提供丰富的联系人管理。
   
4. ThunderBird 借助于 各种个样的皮肤，提供梦幻般的UI。
5. ThunderBird 提供无与伦比的性能。
6. ThunderBird 不会为每个按钮思考过长的时间！而Outlook会。
7. ThunderBird 不会为大的数码照片附件吃光所有的内存！而Foxmail6会。
8. ThunderBird 能为每个邮箱提供单独的文件夹或者提供统一的文件夹，Outlook和Foxmail都只能支持其中一种。

1. 临时性：谈恋爱明显是有项目周期的，从决定开始追求（或者接受追求）对方 时开始，到放弃（项目中止）或者结婚（项目完成）时止。
2. 独特性：很明显，每一个失败或者每一个成功都不是完全一样的，痛苦的人各有各的痛苦，幸福的人也各有各的幸福。
3. 渐进明细：谈恋爱也是按阶段进行，通常所谓的牵手、KISS等等可以作为阶段结束的标记或者称为Milestone。
   

1. 项目干系人对项目的影响越来越小（朋友和父母、情敌等等影响变小）
2. 风险越来越小（失败的可能性变小），这是由于利害干系人的影响导致的风险。
3. 累积成本不断增加（累积花费的money和感情不断增加）
   

1. 项目的成败，项目经理要负最大的责任。
2. 你和你的对象，作为两个不同项目的PM，进行的是两个不同的项目，也许你的项目成功意味这对方项目的失败。
3. 成功的项目是在规定的时间内交付满足要求的产品、服务或者成果。如果时间超过预算（8年抗战型），或者费用严重超出预算，等等，都不能算是成功的项目。
4. 周密的计划和充足的预算增加了项目成功的概率
5. 计划赶不上变化的时候，就要不断的调整计划（变更）
   

1package com.quitgame.common;
2
3public class Parent {    
4    protected int i;
5}

 1package com.quitgame.common;
 2
 3public class Son extends Parent{
 4
 5    /** *//**
 6     * @param args
 7     */
 8    public static void main(String[] args) {
 9        Son s = new Son();
10        s.i += 7; //OK,in the son class.
11        
12        Parent p = new Parent();
13        p.i ++; //OK,in the same package.
14    }
15    
16    public void testProtected(){
17        this.i ++; //OK,in the son class.
18    }
19}

 1package com.quitgame.common;
 2
 3public class ClassInSamePackage {
 4    /** *//**
 5     * @param args
 6     */
 7    public static void main(String[] args) {
 8        Son c = new Son();
 9        c.i ++;   //OK, in the same package .
10    }
11}

 1package test;
 2
 3import com.quitgame.common.Parent;
 4
 5public class SonInAnotherPackage extends Parent{
 6
 7    /** *//**
 8     * @param args
 9     */
10    public static void main(String[] args) {        
11        Parent p = new Parent();
12        //p.i ++; //error , not in the same package , not access througth this son class.
13    }
14    
15    public void test(){
16        super.i ++; //OK,in the son class.
17        this.i ++;  //OK,in the son class.
18    }
19
20}
21

public > protected > package > private

protected 除了可以在子类中访问，还可以在同包中访问。
这次IT大比武，栽在这个修饰符上了。

基线----所有代码起始版本的集合。
如果没有并行开发，基线也许就是版本机上的一个简单文件夹。
如果进行并行开发，那么基线就是具有了指定标签的版本的集合。
在进行并行开发的时候，我们希望基线是流动的，会随着我们的期望变化。比如说我们在1.1版本捉虫的时候开始了2.0版本的开发，我们希望2.0的起始版本保持与1.1的最终版本一致。这里基于一点假设，假设2.0版本不回全面改写1.1版本的代码，而是小部分的改动。这种假设依赖于良好的设计。在扩展功能的时候，对原有代码的改动尽量少。假设我们有A1 - A10 10个文件，在2.0版本中，为了增加新的功能，我们改动了A9，A10两个文件，在1.1版Preview以后，1.1版本中因为修改BUG，又改动了A8，A9两个文件。我们要使2.0版本的初始代码包含1.1版本的最总代码，我们需要做的事情就是将A8按照上篇所介绍的第一种合并场景进行合并，即合并到基线中（简单的移动基线标签），而A9文件，则除了要合并到基线中意外，还要进行上篇所介绍的的第三种场景的合并，即将基线的变化合并到已经发生改变的2.0版本中（移动基线标签并进行合并）。通常，基线变更涉及的文件数应该尽量少。

这就是流动的基线。因基线的变更需要许多人工判断的介入，所以基线应该是稳定经受考验的版本。我们要保证基线的稳定性，不是所有的人都可以随意改变基线，基线也不是每时每刻不断的变化（上篇已经介绍了版本的强制控制）。事实上，基线的变化越少越好。通常基线发生变化也存在常见的场景。

1 1.1版本Preview。如果1.1版本是在分支上进行开发的，那么VM希望将分支上的代码完全合并到主分支上，以避免开发者的代码检入影响版本的稳定性和分支的长期存在对于版本服务器性能的影响。这种合并的工作量比较大，必须借助于一些自动合并的工具进行。
2 版本交替期，即1.1版本已经开始Preview但是并没有RTM，2.0已经开始Coding。这个时候1.1版本的任何将要发布的修改都应该反映到2.0版本的初始代码中，即使是设计的改动（最好不要有）。
3 补丁（包）发布前，Bug的修改明显将导致基线的移动。

跟版本强制控制一样，基线的变更也是并行开发的基础。

未完待续

1 要转产或者上市了，不希望开发者随意的代码检入影响到产品的质量和稳定性
2 已经转产了，希望控制 Bug 的修改，不希望开发者随意的代码检入影响到补丁（包）的发布

版本强制控制的手段

1 将需要保护的分支锁定（仅允许版本管理员修改），打上Release标签
2 让开发者在以Release标签为基线的分支上进行开发
3 登记开发者在以Release标签为基线的分支上的代码修改动作
4 在以Release标签为基线的分支上发布版本进行集成测试
5 对于集成测试通过的代码修改，通过版本合并手段合并到被保护的分支上

上面提到了版本合并，事实上，版本合并也有如下的几种常见情景

1 修改了 Bug ，需要合并到基线版本中，以便可以发布稳定版本

2 修改了 Bug ，需要合并到其他正在开发新功能的代码中

项目的开始，项目组只有从第三方获取的类库、具备编程知识的程序员和PM（项目经理）。由于成员数量不少，使用简单共享方式的版本管理往往难以胜任，某些人往往会因为新功能的需要或者无意将一些代码改得面目全非，无从追踪。我们需要一个简单的版本管理工具，比如Visual Source Safe，每个人在修改代码之前要求先将代码文件标记为“检出”状态，每一次“检入”代码都在服务器上生成一个新的版本。好了，所有的代码都有了版本记录，我们可以查看代码的演进过程，对任何两个版本进行比较，也可以轻松的获取到早先的版本。

开始迭代：

       由于客户的要求，项目开始进行简单的迭代。PM要求所有人员检入可以工作的代码。然后开始执行构建。第一次全部构建的过程可能并不顺利，因为有人修改了A组件导致了依赖A组件的B组件不能正常工作了。当然这个不难解决，我们需要对成员进行培训，要求每个人在检入代码前保证所有的构建都是成功的。这很凑效，虽然每次构建要耗费不少时间。编译的错误很容易发现，但是逻辑的错误却没有那么简单了。不过，到现在为止，这个并不太重要，毕竟项目刚刚开始迭代，在给客户演示的时候偶尔崩溃也是可以忍受的。

版本建立：

       随着项目第一次交付期的临近，PM决定停止新特性的开发，确定1.0版本。并且将这个版本发布SIT（系统集成测试）。刚刚SIT测试的时候，大家都忙于修改自己的代码中的BUG，忙得不亦乐乎。慢慢的，BUG数量曲线开始趋于平滑。很多人开始觉的可以将当前版本发布，从而可以投入精力进行新特性的开发了。PM也这么认为，因为从需求跟踪矩阵的情况看，还有许多的工作量，客户会要求在第二次交付（2.0.x版本）的时候看到剩下的需求都已经实现。为了不影响1.0.x版本的构建，PM下令所有人可以在本地编辑代码以添加新特性，但是不得检入版本机，唯一允许被检入版本机的是修改BUG的代码。这在一段时间里看起来工作得不错，知道有一天，小王发现他在 a.java 文件中添加和编辑了许多的新特性相关的代码，但是 现在要命的是发现了一个跟 a.java 相关的BUG。冥思苦想，小王决定将a.java先备份起来，然后撤销检出，ok，回到1.0.x的代码了，在a.java中修改了一通，检入了，很幸运，居然没有引起问题。小王开始将原先备份的 a.java和修改过BUG的a.java中的更改进行合并，合并的结果将产生一个新的a.java文件，这个文件没有了已经发现的BUG，而且包含了新特性的代码。由于小王是高手，所编写的代码遵从了SRP(单一职责原则)，所以小王的合并并没有耗费缩少时间。但是接下来的时间里，小王又发现b.java,c.java,d.java…x.java需要进行这种手工的合并，每一次合并，他都要将文件预先备份起来。而且，因为在1.0.x稳定运行之前，小王不得检入自己的代码，因此小王担心，如果自己的硬盘崩溃，小王也为不能够使用其它人编写的新特性代码而感到无比郁闷。PM也意识到这种情况，在一个晚上的权衡之后，PM决定在版本服务器上建立了2.0.x的目录，将1.0.x的代码拷贝到这里来。Ok，所有的新特性的开发在2.0.x中进行，所有的BUG修改在1.0.x和2.0.x中同时进行。这真是一个不错的主意。但是，过不了多久，项目组就被频繁的拷贝粘贴折腾的死去活来，代码的修改没有办法被有效跟踪则更是让人伤透了脑筋。

上一篇：并行开发版本管理之路（一） --- 版本管理危机

看完了上篇，我们对于多分支开发容易产生的问题应该有了一些基本的了解吧。事实上，通常，并行开发的版本管理面临以下几个典型的难题

1.  如何保证新版本开发与BugFix同时进行?也就是要求修改过的BUG不能存在于新版本中
2. 如何保证两个新版本并行开发?可能的情况是两个完全不同的版本，或者一个是另外一个基础
3.  如何保证版本的发布不受开发人员无意的代码检入影响?  

不再拐弯抹角了，解决这三个难题的答案是使用分支（这里设计到一个著名的版本管理工具-ClearCase,分支正是其中的重要工具和概念）。