http://www.blogjava.net/sean/archive/2006/12/15/87874.html

上一篇提到NAnt 0.85的两个bug，经过一番折腾，发现问题其实出在它bundle的sharpcvslib(scvs.exe)，我的解决步骤如下：

1- 安装CVSNT，并在编译脚本加入

<property name="sourcecontrol.usesharpcvslib" value="false"/>

让NAnt不要使用那个bundle的sharpcvslib(scvs.exe)，而是使用CVSNT的cvs.exe；

2- 去掉先前由NAnt建议的<cvs-pass>这个Task，以及<cvs-checkout>中的passfile属性；

3- 指定cvsroot中直接包含密码，格式

:pserver:username:password:@xxx.xxx.xxx.xxx:/your/cvs/path

前面提到的文件编码以及用户密码验证等问题均不复存在。

以下谈一谈我的观感：

.NET的开源项目，就NAnt和sharpcvslib来说，不论是代码质量、文档、社区活跃程度、更新/反馈周期，都还有很大的改进和提高的空间，从实际效果来看，感觉.NET部分开源项目的定位和初衷也很值得思考，究竟一个.NET开源项目的存在更多的是要证明.NET/C#也可以做到xxxx，还是要解决实际问题？这背后的价值观到底是什么？

如果是解决实际问题，那么为什么有现成的Win32环境下成熟的、完整的CVSNT可用，却一定要自己搞一套cvs库，而且还要默认使用这个相较而言颇为不成熟的库？如果你跟我说这样是需要对CVS访问有更精细的控制，那我想还不如在CVS的命令行参数上多下些功夫来得实际。

其实CVS已经存在很久，对于基本的协议、标准，现有的不少CVS客户端都实现的比较到位，sharpcvslib不知何故进展如此缓慢，官方站点 sharpcvslib.sourceforge.net最后更新时间是今年2月，上一个发布版本0.35是2004年，开发版本0.36是2005年1 月，NAnt也好不到哪里去，0.85的RC1版本2004年11月就出来了，正式的0.85到今年10月才放出，如果你看看它的bug database，很多bug都石沉大海。

这个版本的NAnt在使用中的一些细节的处理个人感觉也有些欠缺的地方：比如：使用<cvs-checkout>，password属性被deprecated，直接就不支持了，没办法，“官方”建议使用<cvs-pass>那我们就用吧，但是<cvs-pass>和<cvs-checkout>就目前看来，配合的并不默契（详见上一篇随笔和bug ID 1616136）。

相比之下，生活在Java以及GNU/Linux/BSD下的朋友们，在上述这些方面就要幸运的多。

文章来源:http://www.blogjava.net/sean/archive/2006/12/17/88383.html