SVN对比VSS,不知这样够了没

项目	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 行后编辑了一些条件判断.