如何应对变化--闲扯Subversion和Perforce的设计
首先，这两个都是目前使用很广泛的源代码管理工具。P4是商业软件，所以主要用在公司内部，功能基本上是很好很强大；SVN就不用说的，基本上现在的开源项目都用它，open source的。
这不是一篇介绍两种工具的文章，我想说的是两种工具对版本变化的处理方式。
最近出版的《代码之美》里面Karl Fogel专门介绍了一点svn中的增量式编辑器（PS.这本书有些章节的翻译实在是太业余，像动态编程(大一的学生估计都知道是动态规划)、功能性编程(函数式编程最近可是很火的)、界面(结合上下文明显是在说接口函数)这种失误实在是让人怀疑译者的水平），后来专门注意观察了下发现还真是这么回事。举个例子，比如有人向服务器新加了一个文件f.cpp，然后又把它删掉。此后，如果你sync的话大概可以观察到如下的log：
……
Add - f.cpp
……
Delete - f.cpp
……
也就是说svn中记录的都是每一次的变动，或者更直接点就是每一次提交操作。然后在服务器上面将这些操作组织成若干组操作树。当从client发送sync请求的时候服务器要做的就是依次访问某个时间段里面的记录，然后执行相应的操作(比如新增文件、删除或者是更新)。这样即使两次操作本身是可抵消的，比如像上面那样对同一个文件先创建后删除，仍然会简单的执行两次操作，而两次操作的结果实际上就是没有结果:)
但是如果你用P4，对于上面那个f.cpp的操作，比如你同样是sync to head version，那么你不会看到有关于f.cpp的任何操作，因为这个时候repository上面已经不存在这个文件所以也就没有必要通知client端了。因为没有看过相应文档介绍，不敢肯定P4服务器是如何进行版本管理的。不过对于这种情况在P4的log里面观察到的结果貌似是直接对repository文件树进行遍历，而不是依次去处理每一次submission，所以猜测p4内部采用的更可能是基于文件revision的管理方式。当然，这里纯属瞎猜。说不定人家底层还是用的如svn一样的增量式记录，只不过是外围作了一些优化抑或是只是障眼法也说不定。另外，P4中sync到某个change list的时候是怎么处理的没认真观察过，也可能这种情况下跟svn一样。
不过就这两种方法而言（假设我对p4设计的猜测是对的），个人认为svn的增量式记录更像是面向操作，其实版本管理厘米操作就那么几种，这样一来其内部设计和实现上都更简便，而且一旦底层的这种处理方式得以确定，内部开发工作可以大大的得到简化；而P4的设计更趋向于面向数据(这里就是代码文件)，所以内部可能就会更复杂一些，维护和升级估计就不是那么容易，反过来其优点则是在数据的基础上就容易进行特殊的优化处理。说到这里，再回过头去想想本文一开始介绍的一个是商业软件，一个是开源产品，大家是不是想到点什么^_^
实际上对变化的记录和管理是软件设计中一个经常都会碰到的问题，像Undo/Redo、transaction这些技术的核心就是要处理变化。操作系统中的内存页面管理、数据库中的事务，网络游戏中的同步，甚至是一些编程语言的并行处理方式，都可以看到各种变更处理技术的应用。