这几天准备开始一个新项目，由于要求多个人的协作，所以准备使用一个源代码管理系统，很自然的选择了现在很热的Subversion。原来一直没有很好的使用过类似的系统像CVS，只是偶尔用CVS去checkout一下sourceforge或者java.net上面一些项目的代码，但是自己从来没有checkin过。大致看了几篇文章：

Version Control with Subversion

Subversion快速入门

《使用 Subversion 进行版本控制》附录D

然后就开始动手了，中间碰到不少麻烦，最后的步骤总结如下（我是采用Subversion Stand Alone的方式安装的，不是作为Apache的一个模块安装的）：

1. 当然是去subversion.tigris.org下载Subversion了

2. 下载以后安装，建立一个目录repository，然后使用subversion安装目录下的bin子目录中的svnadmin将目录repository创建为一个文档库（我是用TortoiseSVN直接创建的，所以具体的命令行参数我也不太明）

3. 修改repository目录下面的conf文件夹中的两个文件以配置可以使用这一文档库的用户权限，具体的配置方法看看里面的那两个文件很容易就知道了

4. 运行bin子目录里面的svnserve.exe -d -r repository 开启Subversion服务，也可以使用SVNService将Suversion包装为一个Windows服务运行

5. 使用Subversion的客户端如TortoiseSVN或者Subclipse等等连接刚刚开启的Subversion服务就可以了

注意：我原来从来没有正式使用过CVS或者类似的工具，犯了一个大错误，浪费了不少时间。我把我的项目的编译输出（Eclipse里面可能是bin目录这种目录，里面有无数的.class文件）也包括在了版本控制的范围内，结果从Subversion服务器checkout之后的项目Eclipse会自动进行Automatically Build。在构建的过程中会将bin目录下的所有的文件或者目录删除（也包括Subversion进行控制所依赖的.svn目录，应该是一个隐藏目录，里面包括了Subversion要用到的版本控制的信息），这一目录删除了之后，客户端便丢失了版本控制的信息，新建的目录名字又是和原来Subversion中一样的文件名，提交的时候一直出现某某目录“阻碍（obstructed）”或者某某目录不在版本控制之下，导致提交失败。很郁闷的弄了一天多时间终于意识到了问题的原因，解决方法也很简单，就是在创建版本库的时候不要将编译器输出的这些类的目录导入到Subversion上去，在checkout之后构建生成了新的bin或者classes这些目录，也不要将其加入到Version Control，而是选择“add to ignore”忽略这些输出，以后提交或者update就不会有问题了。