这两天不清闲,前后比较了VSS,CVS以及SVN三个源代码管理工具。之前的.NET项目一直是使用VSS来进行管理,只是现在需要向VSS服务器添加大量的文件和文件夹,但是没有找到任何有效的方式能够让我们快速添加,要知道,要添加的文件数量在三万个,通过VSS添加实在是太慢。通过VS2005将项目添加到VSS中去,也是一样,添加几个文件夹,VS2005就死掉了。不知道有其它更好的添加方式。
不过,据说VSS已经被VSTS淘汰了。但是,VSTS实在是太大了,因此,去除了VSS的打算。
之后,打算使用CVS来进行管理。使用CVSNT以及TortoriseCVS,使用Pserver协议,可能是由于我的笔记本问题,其它人访问CVSNT速度很慢,主要是通过验证的时候很慢。上网查,发现确实如果文件个数很多的话,CVSNT的特点就显现了,速度慢。因此,将CVS放弃。可惜了,我对CVS的概念还是相当熟悉的,没有用上。
之后,就是打算使用SVN来管理了。SVN相对CVS有一些改进,主要的改进在于提供更多的权限访问控制,访问速度也有提高。另外,配置上也要简单一些。因此,就使用SVN了。SVN1.4.5 + TortoriseSVN就好了。
权限管理的问题,在SVN1.2之后已经有一个比较好的解决方法。通过passwd定义用户名和密码;通过authz定义文件级别的访问控制。网上有一篇文章讲这个,比较清楚,但是换到我这边,总是不能使用[Repository:/path/to/file]的方式,未果,只能使用[path/to/file]的方式,搞定了权限的问题。
但是,最关键的问题,是要支持不同权限用户的编译。之前采用Firefly配置库进行管理,需要管理classes,classes所有人都有。编译文件通过classes生成所需要的lib文件。这种方式需要我们既edit src又要edit classes,增加了程序员的负担。
因此,我需要找到一种方法:只需要edit src就能够编译。方法也很简单,但是由于以前的代码目录实在是比较复杂,一时要完全改掉换成新的结构,没有问题,但是怕有其他暂时没有想到的问题,因此决定先保留原来的目录结构,改变编译方式。
经过一个下午的奋战,搞清楚了。将以前classes生成的JAR直接放在common lib下,然后改变编译的classpath,让从现在的lib中找,而不是从classes文件中找。此外,当用户还有源代码的时候,编译生成jar包需要替换common lib下的JAR包,这样才能保证JAR包总是最新的,能够被所有人访问,这样就解决了权限和编译的问题。
目前测试已经通过,当然按照敏捷的思想,我认为代码集体所有还是一个趋势,以后不需要在开发人员内部做权限控制是最好的。慢慢来吧。
Label和Branch在配置管理过程中是很重要的两个概念。
Label:用于对文件进行标记特定的版本,对一堆文件标记之后,可以将具有同样标记的文件给取出来。
Branch:分支。建立分支,形成可以物理独立的空间,这样每个Branch就可以单独演化,如果有需要的话又可以融合。
为什么需要Branch呢?这个得回答配置管理的根本问题,是为了让团队成员中共享。但是,有些时候又必须在小的团队中共享,在大的团队中反而不能共享。比如说:为了客户A定制的兄弟和为了客户B定制的兄弟可能代码都是基于某一个主干版本。因为客户A,B所以有了BranchA,BranchB,当然还有岿然不动的主干版本。由于有三波人马为了不同的目标而工作,都需要改动很多共同的代码。如果都放在同一个版本中是无论如何也做不了这件事情的。
所以,Branch是为了解决共享冲突的问题,让各个分支团队能够更好的并行工作。在vss中,branch支持得很不好,在CVS中对于Branch支持得还是不错的。
在实际情况,我们可能更多的是需要Label,而不是Branch。我们需要标记,用于检出我们发布的某个版本的代码。这样当我们前行的时候,不至于找不到之前的版本:)