公司强制使用VSS，用SVN惯了，很不爽。整理了下面的对比，请指正
VSS与SVN的对比整理
伪秀才
Shicheng.yan@gamil.com
2008-9-27
|
项目
|
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 行后编辑了一些条件判断.