配置管理

这两天不清闲，前后比较了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。我们需要标记，用于检出我们发布的某个版本的代码。这样当我们前行的时候，不至于找不到之前的版本:)