请大家帮忙反驳公司强制使用VSS的理由

反驳啥呀，别反驳了，他之所以要求使用VSS，不就是担心大家提交代码时出现混乱和冲突么（虽然VSS比较死板）？跟他搞VB的还是搞啥的没关系。他就是想减少出乱子的风险。
如果你反驳了，比如用svn了，但公司对开发人员版本控制方面的培训又不到位，一些毛手毛脚的新手乱用版本控制。到时候出了乱子，人家可就要怪你喽。

是的,VSS不安全,其中任何一个软件人员可有意无意的删除整个共享目录,ADMIN口令也有很多解密工具软件了.

仅一个理由就几乎可以枪毙vss了：  vss不支持本地快照，只支持服务器快照，不能记录和复现特定版本。

举一个例子说：一个系统有A、B、C模块，在一个月黑风高的夜晚，三个模块的（服务器上）最新版本分别是1.2、1.5、1.7，这时候，杨白劳的本地环境上的版本是1.2、1.5、1.6，他发现了一个该死的bug，别人都没有发现，他需要在其他环境上复现这个bug的现象。

如果民工团用了vss，杨白劳应该怎么做呢？他不能够靠打一个label来让另外一个人用这个label来get这个版本吧？因为如果他这时候打了label“i_hate_vss”，那么白毛女用“i_hate_vss”拿下来的版本会是A1.2、B1.5、C1.7，而不是杨白劳本机上的A1.2、B1.5、C1.6。 

想像一下如果杨白劳是部署管理员的情形，测试服务器上跑着过去的版本，而这个版本的源代码永远没有办法简单的复现了， 面对bug，这是多么令人绝望的情形啊！

cvs&svn不仅支持服务器快照，也支持本地快照， 不管某个本地环境被尘封了多少年，同样可以对它打本地快照，在任何另外的环境都可以一模一样的复现这一套代码版本。

有机会的话，赶紧抛弃vss吧， 微软买来之后几乎从来没有用过，也没打算升级，我用过2005版本，和6.0几乎一样，换汤不换药。

说到底， 策略上vss是悲观锁，但从管理上说用vss的团队都是超级乐观的，他们基于下面的假设：
    项目规模永远不会增大到冲突增加造成工作量非线性上升的程度。

这个假设是正确的么？ 悲观锁策略的线性近似逼近区间的上限是多少人或者多少功能？现在开发的东西，将来还会不会形成产品继续实施？

如果在以上问题上做了乐观的估计，很多团队会倾向于使用vss，但很不幸的，等到他们发现冲突增加的时候，进度压力会让他们不愿也不敢换用采用乐观edit-merge-commit策略的配置管理工具了。

这时候，很多人会延迟更新（因为害怕更新会破坏build），会本机维护私有版本（因为服务器共有版本被其他人checkout），checkout、checkin的周转率变得越来越慢。临近项目组陷入焦油坑的底部的时候，人们到处在寻找可以编译的黄金版本，项目经理每天在考虑什么时候开始集成下一个“黄金版本”。。。

上帝饶恕这些乐观的无知无畏的阶级兄弟们吧！
   

vss 只是局域网吧

svn的branches和tag功能,这个是VSS没有的,是SVN的一大特色.
假设,楼主发布了一个版本对外运营,接着开发新功能.同时,运营过程中ABC等十个文件发现了BUG,可你已经为了开发新功能修改了ABC等二十个文件.
怎么办?
查到历史记录手工凑齐一份历史版本,修BUG,再在目前最新版本中再修一次?
手工?不妥.

使用SVN就可以很好地解决问题.
只要对历史版本签出一个branches,(甚至,只要记得发布时间,找出恰当的版本号,事后于签出一个某年某月某日的版本,也是一瞬间自动化完成的).在branches上修改,测试,然后自动合并到trunck上去.

还有楼上说的,多人同时修改一个文件.

其实说到底,这是由于SVN有强大的自动合并功能.是由于SVN底层机制(记录差异而非复制)而拥有的.
这是VSS所不可能具备的.

SVN比VSS强大很大,楼主在这个问题上一定要坚持啊.千万不能妥协,宁可辞职也不能让步.否则以后,当想使用SVN这些优点的时候,受累的是你们自己啊 .

至于SVN对比CVS的优点,楼主可以看SVN的官方说明.

看到这句实在想回一个 是人都知道装个插件eclipse就可以用VSS了。。

从效率、成本等各个方面来说，统一版本控制工具，利大于弊。

至于是否一定要统一到VSS，的确可以商量。但作为PMO来说，完全可以这样要求。

最多争取Java开发人员都统一到SVN，但不可以说不能统一到VSS。

实在没兴趣把所有的都看完,不过据我了解,VSS现在也支持Http的连接,以及其享签出然后再合并的模式.可以看看最新的VSS的文档.