同时开发C/C++和JAVA，如何选择VSS和CVS？

一般来说，做版本控制常用的软件有CVS和VSS。

如果选用CVS，开发JAVA程序时，有很多IDE集成CVS客户端，使用非常方便。
但是开发C/C++，使用visual studio的人员该如何使用CVS？
使用TortoiseCVS这样的第三方软件联系CVS和studio吗？
这样的使用方式，将会给studio开发者带来怎样的困难？
Studio + TortoiseCVS - ?
Eclipse - OK
Jbuilder - OK

如果选用VSS，studio开发者相信会很方便，JAVA开发者可以使用第三方软件或插件与VSS集成。
但仍然会遇到一些问题，象Eclipse用户使用Vssplugin时，由于取得的文件是只读的，重构几乎不能进行。
还有另一个问题，如果开发者在外地，能否通过Internet（安全的）连接VSS服务器？
Studio - OK
Eclipse + vssplugin - work,but limited
Jbuilder - OK

我希望清楚两者间的利弊，以便权衡。

背景

    * 开发工具：.net studio, JBuild, Eclipse, MS office, UltraEdit, DW MX
    * 文件格式：文本文件，二进制文件

使用VSS

.net studio,JBuild内置集成，Eclipse可使用第三方plugin集成，不影响基本开发。另外，可使用VSS客户端，间接使其它开发工具可以编辑VSS文档。VSS安装配置简单，与MS工具的集成相当良好。

    * VSS的性能是一个重要的考虑点。举例说，1000个文件的同步时间约为1分钟。这对项目的开发方式有很大影响。

    * 其次，我没有发现如何浏览VSS的提交记录。这点对于我们相当重要。因为我们都非常重视版本控制和跟踪。当VSS帮不上忙，我们惟有以手工的方式记录每次冗长单调的修改内容，这在长时间里是让人气馁的。人们当觉得事情是困难的时候，会不自觉地选择避免它。这在软件开发中也一样。坚持频繁地编辑大量的、没有直接价值的修改记录，绝对是极大的困难。从想象中、从众多的案例中，我们可以知道使用技术手段保证SCM无疑比行政手段要有效得多。同时，也低成本得多。因此，我们应该期望SCM软件有此功能。

    * 第三，不能安全的面向Internet环境。这是VSS的访问机制决定的。当日后两地的程序开发交互越来越频密的时候，面向Internet将是必须的。

    * 第四，并发能力较差。一般来说，VSS适合6人以下小组并发开发。它的checkout and lock机制将给小步开发，持续集成造成影响。VSS也有checkout not lock机制，但不知道发生冲突时它是如何解决。若每次都使用手工解决，将是非常庞大的工作量。

    * 最后，VSS的可选客户端不多，功能也相对贫乏。

使用CVS

Eclipse,Jbuilder内置集成，其它开发工具只能依赖第三方CVS客户端访问CVS。不过，CVS的可选客户端比较多，其中最方便的FOR WINDOWS客户端是TortoiseCVS.

基本上，使用CVS可以不必担心上述在VSS中提到的问题。关键是如何更好的与MS开发工具集成。开发人员是否愿意使用第三方工具，间接让开发工具与CVS集成。


选择CVS的首要关注点是它间接带来的生产效率。良好的性能的确可以让我们工作得快一些，但这仅是表面的。

    * 1，同步/提交得快，我们会愿意频繁的提交，细粒度的推进项目。CVS就象齿轮的止逆爪一样，保证我们的项目一步步前进。
    * 2，时刻保持CVS仓库代码最新，自动的持续集成就有可能。使用第三方工具，从CVS中check out最新代码，运行测试，记录每天的通过率和buglist。
    * 3，由于非独占性的check out就可以实现集体代码所有方式，当发现一个必要的改动时，我们可以立刻把它修正，而不必担心冲突。因为，即使我们同时在一个文件里修改，CVS也有可能透明的为我们合并各自的工作。即使不能自动合并发生冲突，手工合并也不会太复杂。

分别使用VSS和CVS

这算是一个折衷的可行方案。


朋友的补充和更正

补充一点 - 关于提交记录的浏览，根据我的经验VSS还是提供了相应功能的，包括：

    * 1. Check in/out的同时可以提交关于本次操作的说明信息
    * 2. 可以针对整个工程、子文件夹或者单个文件进行历史修改记录的查询，查询条件包含修改时间、修改人等等，查询结果就是历史修改记录的列表
    * 3. 可以选择历史修改记录列表中的任意两条记录，进行比较。也就像是WinDiff或者UltraEdit的比较功能一样进行两个版本的文件的比较
    * 4. 将文件版本rollback回到历史修改记录列表中的某一个版本。

一般来说远程访问VSS，就是通过VPN了。由于我惨痛的VSS经验，让我对VSS深深的恐惧。

TortoiseCVS结合在资源管理器里面的，没有什么不方便的。yygw他们的Delphi项目cnpack用CVS就用得很好，也没有见过他们说Delphi就不能很好的结合TortoiseCVS的说法。

Robbin是不是太忙了？这几句话不够说服力啊。希望有机会可以直接和你聊两句。

你上面列出来n多VSS的缺点和n多CVS的优点了，我也没有什么好补充的了。

VSS对我来说就是很惨痛的东西，修改之前要锁定方式checkout，修改之后，在checkin，那么多人工作，你总不能把所有的东西都checkout吧？那么你就会很痛苦，碰到一个要改的文件，就要去checkout，一个一个操作，文件一多，要改的地方多了，就非常头疼了。

CVS的主要缺点就是Subversion的卖点，个人觉得CVS不太适合管理文档(因为文档都是二进制的，cvs又不支持重命名)，CVS更加适合管理源代码。

此外VSS的性能是非常糟糕的，又不支持Internet访问，我是从来不考虑这个东西的。

好象没有人尝试过VSS的共享模式阿，我也只是简单看了一下，VSS确实是可以在不锁定的时候让两个人同时编辑一个文件的，所以也一直很奇怪，为什么大家都用锁定checkout的方式使用VSS呢？可惜我原来在公司没有权力，我们的头坚决认为锁定checkout才够稳定，晕......

就好像CVS也支持锁定模式，但是肯定不会有人去用锁定模式一个道理。

不一样吧，我不用锁定模式又不是因为CVS，是因为这样开发效率高阿。

VSS只是一个MS的玩具，MS自己都不用它。
至于CVS和SVN，我建议如果你没有使用CVS的经验，还是选择SVN的好，那样你就不会被一些象原子提交这样的概念所困扰。同时SVN的学习曲线相对低一点，稳定性和对于web的支持也稍微好于CVS。但是由于大量的CVS的使用，造成了在CVS积累的经验更加多。因此找到一个合适的CVS管理者要容易的多。而一个好的SCM管理员要比工具重要的多。

最近偶接触的一个项目就是用Subversion， 发现它真是一个很好的工具，曾经在CVS上遇到的那些麻烦问题都没有了.....看上去，它有很好的前景会成为open source下一代版本控制标准工具