Why CVS/SVN is not great for me?

在我介绍了Mercurial — DistributedSCMsishen提了一个问题:为什么要从集中式SCM(Centralised SCM)转到分布式SCM(Distributed SCM)?一些理由在OpenJDK选择SCM的时候已经说明:

概括地说:to support large-scale, distributed software development.

1、A branch is just another repository, not some state in a central database. You can create branches at will to explore new ideas and, equally easily, simply delete them if things don’t work out.
2、You don’t need to be connected to a server—or even be on the network—in order to get work done.
3、You don’t need to set up and manage a central SCM host with sufficient disk space, compute power, bandwidth, and backup to support the concurrent SCM operations of your entire development community.

其中的1,2个优点对我而言是很有吸引力的。使用CVS/SVN的行为准则是如果对代码有少许的改进,那么就鼓励往中心仓库提交并且标注tag。然而我发现这种行为假设在实际中往往存在缺陷。因为有一些改进需要比较长的时间来反复试验,我把实验的步骤叫做baby steps,只有当baby steps最后达到预期的目标,这是用户(编程人员)才会往代码版本控制服务器提交改变。换而言之,需要一个change set(local source repository)来控制baby steps,同时能够把chage set push到remote source control server。下面是示意图:

 Jack's SCM

上面的想法可以在Eclipse或者IntelliJ IDEA看到雏形。IDEA的File History做得比Eclipse的Local History更加出色在于用户可以对某一时期的改变标注lable,这无疑让“Rollback to Revision”这类操作更方便。

localaddlabel.gif localhistoryforselectionview.gif

IDEA的内迁History可以解决上述的一些问题,但是如何把两者结合起来,提供用户一个单一的版本控制的Interface,我想这是Distributed SCM应该考虑的一个问题。

另外: sishen对distributed scm的理解