公司强制使用VSS，用SVN惯了，很不爽。整理了下面的对比，请指正
VSS与SVN的对比整理
伪秀才
Shicheng.yan@gamil.com
|
项目 |
VSS |
SVN |
备注 |
|
原子性提交 Atomic commit |
不支持 |
支持 |
SVN无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN都会自动“回滚”(rollback)操作。换一个说法，SVN保证所有的修改要么全部入库生效，要么个也不入库，即对版本库不作任何修改。 |
|
重命名 |
不支持 |
支持 |
这对Java和C#开发很重要，为了得到更好的代码，开发中需要经常进行重构，重构就经常涉及到文件的重构名，有时会对文件重命名再提交。 |
|
最小提交块 |
文件 smallest commit block is a file |
行 a line is the smallest commit block |
最小提交块是文件，这样通过看历史很难找出某次checkin到底checkin了什么东西 |
|
安全性 |
基于文件系统共享实现对服务器的访问，需要共享存储目录 |
SVN服务器有自己专用的数据库，文件存储不采用“共享目录”方式，所以不受限于局域网。客户端可以是不同的平台，都是通过tcp/ip和特定端口来访问SVN服务器，有不同安全等级的访问协议可供选择 |
是不是每次使用VSS的时候得登记一次服务器？麻烦了吧 |
|
离线开发操作 |
需要执行几个步骤也可以安全入库，但麻烦 |
不需要另外操作 |
|
|
模式 |
主要采用独占模式（checkout,modify,checkin）也可以使用（multi_checkout,modify,checkin,merge）模式。 |
使用update,modify,commit方式。每个人可以修改自己可以访问的任意代码，代码不会被一个人单独占用。可以多人修改同一份代码，并且每个人的修改结果都不会丢失。如果提交时SVN没有发现冲突，则代码可以直接入库。否则SVN会让你手工合并 |
|
|
Internet网络和远程协作 |
VSS8.0支持 |
更适合基于互联网协作开发，速度快 |
|
|
支持平台 |
Windows |
Windows,Linux,Unix works on windows, linux, unix, and even macs and also java which makes it ultimaly portable |
|
|
支持开发工具 |
VS6, VS.NET2005, VS.NET2008(不过有个bug) VSS Plugin for Eclipse |
SVN for VS.net 2005 Plugin-AnkhSVN, 也支持vs.net2008, SVN for Eclipse |
|
|
客户端 |
VSS client |
Windows下：TortoiseSVN，Linux下：RapidSVN |
|
|
自动合并 |
据说VS2005中也支持了？ |
提供，如果不能自动合并，可以手工修改冲突 |
|
|
|
|
多版本分支的合并 |
|
|
版本分支 |
有 但在操作中VSS首先要做项目共享,引入要分支的项目或文件然后做分支操作 |
有 自动建立分支 |
|
|
异地开发 |
支持 |
支持 |
|
|
操作的便利性 |
安装、配置、使用均简单，很容易上手使用 |
安装、配置较复杂，但使用简单，只需对配置管理做简单培训即可 |
|
|
版本管理 |
手工 通过label来自定义一个版本号，可以解决部分项目管理的问题，但这是远远不够的，当一个产品根据用户需求产生一系列不同的项目版本时使用VSS将难以管理 |
提交时记录版本号，自动分支管理 |
VSS版本发行时只能手工挑选对应的版本文件进行发布。 |
|
与外围工具集成 |
|
各种各样的外围工具（主要是服务器端），满足多种需要。如果有需要也可以自己写插件或管理脚本，开放的架构，允许我们这样做。 |
|
|
费用 |
商业 proprietry |
开源免费 open source (Apache/BSD-style license.) |
|
微软自己不用VSS，它用啥？SouceDepot！
不同意很多人说的“工具够用就行”，就算是两件工具可以完成完全一样的功能，其设计哲学和使用方式上肯定也会有区别。如果是每天必用的工具，不够便利的，或者蹩脚的使用方式会持续的影响你工作时的心情，而谁又愿意每天工作时都被工具逼得心情不好？
http://www.javaeye.com/post/583660?page=1
使用VSS，如果我周末回家办公，怎办？把代码全部checkout，再通过vpn连加VSS。
反对：如果我是甲方，要审查你的代码，svn可以直接通过http浏览代码，非常轻松，而VSS，还得装VSS客户端（license谁给？），还要用VPN连到乙方的局域网里（人家也得要有VPN啊，许多小公司网络是租用的没有vpn）
Subversion比VSS强的一个地方是如果文件改名了，以前的历史记录不会被丢失。呵呵，打个比方，Subversion就像一个聪明的警察，尽管罪犯虽然改名或整容了，但是他的前科还是被这个聪明警察给顺藤摸瓜给记录下来了。而VSS就像一个有点健忘的警察，罪犯名字一改，VSS就完全忘记了他的前科。
VSS 和 SVN/CVS 在锁定和非锁定上的处理源自应用环境的不同.
VSS 产生于微软这样的 close source 的企业, 而在这样的企业里, 开发软件时, 团队成员间通常就在一个办公室里, 文件的锁定/解锁的协调相对容易, 任务也许可以真的分配到一个人就在一个文件上工作; 但, 在开源世界里, 开发人员来自世界各地, 在世界的每个角落/不同时间里参与着项目的开发, 如果你今天在北京把一个文件锁住, 晚上没做完, 没提交, 然后睡觉去, 我们美国的同志们若也参与这个功能的开发, 那么在北京时间凌晨 2:00 的时候, 你尚在美梦中, 而那边已是早上 9:00 的工作点, 这样就没法对这个文件进行修改, 只能等到你呼呼睡醒, 北京时间 9:00 上班, 而美国那边已经是 16:00, 浪费大半天, 该下班了...
那么我们在公司里, 是不是其实应该很适合用 VSS 呢? 举个简单的例子就知道不行了 - g20 项目中我们有个 g20.js 的文件, 所有 ajax 相关的功能都在这个将近 6K 行代码的文件里完成, 我们的同学们经常需要同时并行着做两个以上的功能, 这使得我们不可能采用锁定的模式. 而 SVN 的拷贝-修改-合并模式并没有在现实中带来想像中的那么多 "冲突" - 只要功能拆解得当, 不会出现两个人同时修改同一个文件同一行的情况, 最常见的情况就是你在 200 行后加了个 function, 我在 300 行后编辑了一些条件判断.
