Many developers nowdays are moving from VSS to SVN. If you will search for "SVN" and "VSS" in Google, it will show you lots of articles related to VSS to SVN migration.
VSS's lock-modify-unlock model makes collaboration on rapidly-changing files a major headache. Plus the overhead of needing an admin to unlock files that someone has checked out while they're on vacation.
With VSS, it's not a question of if you'll lose data - it's WHEN. Your source repository is supposed to be a rock - if a developer's workstation crashes, you should only have lost HIS changes. You shouldn't lose random files and data from the repository
VSS hasn't been maintained by MS in over 6 years. Can you even get support for it anymore?
Depending on your backup tools, you may not be able to get a complete backup of your VSS repository if you have just one person left logged into the server (meaning they left their dev tools open, or left the VSS client running).
VSS requires that all users have nearly full control, at the filesystem level (NTFS permissions), of the files that make up the repository.
There is no good, usable, easily available published API for VSS and 3rd-party tools are weak for the most part.
Merging sucks in VSS.
VSS: If you have developers spread across multiple timezones, the very act of both of them checking in can corrupt the database if they check in too close together, in the wrong order.
Now, this isn't to say that Subversion is faultless - there are certainly things it could do better, and things it doesn't do at all. But all the people who worked with VSS and SVN most likely will never come back to VSS.
If you will choose SVN. Here is a list of tools you may need:
AnkhSVN is a Subversion SourceControl Provider for Visual Studio.
TortoiseSVN is an easy to use SCM / source control software for Microsoft Windows and maybe the best standalone Subversion client there is.
VisualSVN is a Visual Studio plug-in that integrates Subversion and TortoiseSVN seamlessly with Visual Studio.
VisualSVN Server is a package that contains everything you need to install, configure and manage Subversion server for your team on Windows platform. It includes Subversion, Apache and a management console.
Another good alternative to VSS and SVN is SourceGear Fortress which has Issue Tracking system in addition to source control - all in one. Or SourceGear Vault - source control only. Also there is SourceAnyWhere solution. If you need Microsoft solution than go with TFS instead of VSS.
Microsoft 承认从未在其任何内部项目中使用 VSS（不过现在找不到参考资料:/）。 我用了两年了，效果很糟糕。 数据库每周至少损坏一次。
另外，我最喜欢向 VSS 用户引用的内容之一是 Eric Wadworth 页面上的第一句话，据报道来自微软的某人：
“Visual SourceSafe？打印出所有代码会更安全，
将其通过粉碎机，然后将其点燃。”
一定要选择 SVN。 VSS就像1000个恶魔的噩梦。
Microsoft has admitted to never using VSS on any of their internal projects (can't find the reference right now though :/). I used it for two years and it was stupid bad. Database was corrupted at least once a week.
Also, one of my favorite things to quote to VSS users is the first quote on Eric Wadworth's page, reportedly from someone at Microsoft:
"Visual SourceSafe? It would be safer to print out all your code,
run it through a shredder, and set it on fire."
Definitely go with SVN. VSS is like the nightmares of 1000 demons.
We use SVN where I work and with the right documentation, right client and tools it is a snap - so far it is highly reliable to work with. After having spent the past 10 years with VSS I can say I don't miss it a bit.
VSS is old and outdated. The database gets corrupted way too often. There's a reason why MS built TFS too.
SVN is very popular (meaning lots of community support, meaning free support), there are many tools that hook to it (CruiseControl for Continuous Integration for example) and it's rather simple to use.
You have to consider there's a learning curve if you are already using VSS and that's something that you have to weigh in your research. If the other developers haven't used SVN (or CVS) then it could be costly, although all you need is one person who really gets to know the system and then coach the rest.
We did change from VSS to SVN 4 years ago and we haven't looked back since.
顺便说一句，我们多年来一直非常愉快地使用 Sourcegear Vault。 拥有存储库和中央 SQL Server 数据库以及通过互联网进行的良好访问使我们的组织变得轻而易举。
我认为它的价格很合理，至少值得一看。
Just as an aside, we've been using Sourcegear Vault for a number of years quite happily. Having repositories and a central SQL Server database along with great access over the internets made it a slam dunk for our organization.
I think it's reasonably priced and at least worth a look.
If you had Visual Studio integration as a requirement, I would have warned against SVN even a year ago, but that's changed in a big way. It's still not as good as, say, VS Team System, but it's much better than the old MSSCCI-based VSS integration. There's no reason not to use SVN with .NET.
Almost Definitely SVN. SVN sports a different way of working (Copy-Modify-Merge instead of Lock-Modify-Unlock). It's a bit of a learning curve, but it's the way things have gone for several years now, so most devs will have to learn it at some time or other anyway. Lock-Modify-Unlock is way too much of a pain, and there are serious collaboration problems that it actually contributes to, which I'd be happy to explain if you're curious.
Seconding the comments about how bad VSS is as well. Here are various links that cover the topic:
Speaking as someone who went through the VSS -> SVN transition process for a large codebase, I would say the biggest benefit is being able to sleep soundly knowing that your SCM system wont suddenly have a hiccup that corrupts your database and you have to go back to yesterday's backup. You do backup your database daily, right?
With VSS, corruption happened at least once per month. With SVN (same hardware & OS) - not once in over two years.
Oh, and the branching/merging capabilities are sweet!
出于上述所有原因，当然应该选择 SVN。 你可以尝试 ankhsvn 这是一个 Visual Studio 的 svn 插件。 这样您就可以两全其美：使用 SVN，所有工作仍然在 Visual Studio 内完成。
Definitely, go with SVN, for all stated reasons above. You could try it ankhsvn which is a svn plugin for visual studio. This way you get the best of both worlds: using SVN and all work still gets done inside visual studio.
Team Foundation Server is the optimal choice for developing in the .NET world. However it is not free and for the current version 2008 it can be quite expensive. If you have higher level package for Visual Studio you do get TFS workgroup edition for free which allows 5 users access for no additional cost.
There are some major caveats to the workgroup edition you must use one of the 5 slots for the TFS service account unless you set it up to run under a users account that will be included in the TFS member list. The other is once you hit your 5 user limit the jump to 6 users is a fairly staggering cost as the current license requirements include the need to purchase the server (a few thousand dollars) AND CALs for every member of the team. That's a fairly prohibitive cost to add one more member to the team.
发布评论
评论（16）
SVN比VSS更流行并且有很多优点。 VSS 已经过时了。
现在许多开发人员正在从 VSS 迁移到 SVN。 如果您在 Google 中搜索“SVN”和“VSS”，它会显示许多与VSS 到 SVN 迁移。
现在，这并不是说 Subversion 是完美无缺的 - 当然有些事情它可以做得更好，有些事情它根本没有做。 但所有使用过 VSS 和 SVN 的人很可能永远不会再回到 VSS 了。
如果你会选择SVN。 以下是您可能需要的工具列表：
这是一本关于这个主题的好书：Version Control with Subversion 作者：C Pilato
< a href="http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg" rel="noreferrer">版本控制使用 Subversion http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
VSS 和 SVN 的另一个不错的替代方案是 SourceGear Fortress，除了源代码控制之外，还具有问题跟踪系统 - 全部合而为一。 或 SourceGear Vault - 仅源代码控制。 还有 SourceAnyWhere 解决方案。 如果您需要 Microsoft 解决方案，请选择 TFS 而不是 VSS。
SVN is more popular than VSS and has lot's of advantages. VSS is old and outdated.
Many developers nowdays are moving from VSS to SVN. If you will search for "SVN" and "VSS" in Google, it will show you lots of articles related to VSS to SVN migration.
Now, this isn't to say that Subversion is faultless - there are certainly things it could do better, and things it doesn't do at all. But all the people who worked with VSS and SVN most likely will never come back to VSS.
If you will choose SVN. Here is a list of tools you may need:
Here is a great book on this subject: Version Control with Subversion by C Pilato
Version Control with Subversion http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
Another good alternative to VSS and SVN is SourceGear Fortress which has Issue Tracking system in addition to source control - all in one. Or SourceGear Vault - source control only. Also there is SourceAnyWhere solution. If you need Microsoft solution than go with TFS instead of VSS.
Microsoft 承认从未在其任何内部项目中使用 VSS（不过现在找不到参考资料:/）。 我用了两年了，效果很糟糕。 数据库每周至少损坏一次。
另外，我最喜欢向 VSS 用户引用的内容之一是 Eric Wadworth 页面上的第一句话，据报道来自微软的某人：
一定要选择 SVN。 VSS就像1000个恶魔的噩梦。
Microsoft has admitted to never using VSS on any of their internal projects (can't find the reference right now though :/). I used it for two years and it was stupid bad. Database was corrupted at least once a week.
Also, one of my favorite things to quote to VSS users is the first quote on Eric Wadworth's page, reportedly from someone at Microsoft:
Definitely go with SVN. VSS is like the nightmares of 1000 demons.
考虑使用更现代的工具，例如 Git、Mercurial 或 Darcs。 有很多优点，我将把谷歌搜索作为练习留给读者。
Consider a more modern tool like Git, Mercurial or Darcs. There are plenty of advantages, I'll leave the googling as an exercise to the reader.
我们在工作中使用 SVN，只要有正确的文档、正确的客户端和工具，一切都变得轻而易举 - 到目前为止，它的工作可靠性非常高。 在与 VSS 一起度过了过去 10 年之后，我可以说我一点也不怀念它。
我非常喜欢 SVN，所以我写了一篇关于我认为最有价值的客户（有些不是）和其他工具的评论。 这是一篇新文章，所以非常及时： http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/
我会毫不犹豫地向任何人推荐 SVN - GIT 是我名单上的下一个看着..
希望这有帮助。
We use SVN where I work and with the right documentation, right client and tools it is a snap - so far it is highly reliable to work with. After having spent the past 10 years with VSS I can say I don't miss it a bit.
I like SVN so much I wrote a review of what I consider to be the most valuable clients (some are not) and additional tools. This is a new article so it is very timely: http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/
I would not hesitate to recommend SVN to anyone - GIT is next on my list to look at..
Hope this is helpful.
避免源安全数据库崩溃带来的麻烦以及整个代码库的崩溃是一件大事。
不必担心谁签出了文件是另一回事。
Avoiding the headaches of a Source Safe database crash taking your whole codebase with it is a biggy.
Not having to worry about who has a file checked out is another.
我发现用 VSS 合并文件非常麻烦，但用 SVN 就很好了。 另外，我没有任何证据证明这一点，但 SVN 似乎更快。
I find merging files with VSS to be very cumbersome, but it's great with SVN. Also, and I don't have any evidence of this, but SVN seems faster.
VSS 已经过时了。 数据库经常被损坏。 MS 也构建 TFS 是有原因的。
SVN 非常流行（意味着大量的社区支持，意味着免费支持），有许多工具可以连接到它（例如用于持续集成的 CruiseControl），并且使用起来相当简单。
如果您已经在使用 VSS，则必须考虑到学习曲线，这是您在研究中必须权衡的因素。 如果其他开发人员没有使用 SVN（或 CVS），那么成本可能会很高，尽管您所需要的只是一个真正了解系统然后指导其余人员的人。
四年前我们确实从 VSS 更改为 SVN，从那以后我们就没有回头。
VSS is old and outdated. The database gets corrupted way too often. There's a reason why MS built TFS too.
SVN is very popular (meaning lots of community support, meaning free support), there are many tools that hook to it (CruiseControl for Continuous Integration for example) and it's rather simple to use.
You have to consider there's a learning curve if you are already using VSS and that's something that you have to weigh in your research. If the other developers haven't used SVN (or CVS) then it could be costly, although all you need is one person who really gets to know the system and then coach the rest.
We did change from VSS to SVN 4 years ago and we haven't looked back since.
顺便说一句，我们多年来一直非常愉快地使用 Sourcegear Vault。 拥有存储库和中央 SQL Server 数据库以及通过互联网进行的良好访问使我们的组织变得轻而易举。
我认为它的价格很合理，至少值得一看。
Just as an aside, we've been using Sourcegear Vault for a number of years quite happily. Having repositories and a central SQL Server database along with great access over the internets made it a slam dunk for our organization.
I think it's reasonably priced and at least worth a look.
AnkhSVN 2.0 真的非常好。
如果您需要集成 Visual Studio，我什至在一年前就会警告不要使用 SVN，但现在情况发生了很大变化。 它仍然不如 VS Team System 那样好，但比旧的基于 MSSCCI 的 VSS 集成要好得多。 没有理由不将 SVN 与 .NET 结合使用。
AnkhSVN 2.0 is really very good.
If you had Visual Studio integration as a requirement, I would have warned against SVN even a year ago, but that's changed in a big way. It's still not as good as, say, VS Team System, but it's much better than the old MSSCCI-based VSS integration. There's no reason not to use SVN with .NET.
这里又进行了一次“绝对是 SVN”投票。 我之前的工作是迁移团队的一员。 我无法告诉你摆脱 VSS 是多么美好。
我可以继续，但是 VSS 束缚的记忆太痛苦了。 拒绝吧。
Another "definitely SVN" vote here. I was part of a migration team at a previous job. I can't tell you how nice it was to get rid of VSS.
I could go on, but the memories of the VSS shackles are too painful. Just say no.
SourceGear Vault 是 VSS 的绝佳替代品。 它最初是“VSS 功能，但使用真实的数据库”，并从此发展。
SourceGear Vault is an excellent replacement for VSS. It started out being "VSS features but using a real database", and grew from there.
几乎肯定是SVN。 SVN 采用不同的工作方式（复制-修改-合并而不是锁定-修改-解锁）。 这是一个学习曲线，但几年来一直如此，所以大多数开发人员都必须在某个时间或其他时间学习它。 锁定-修改-解锁太痛苦了，而且它实际上会导致严重的协作问题，如果您好奇的话，我很乐意解释这一点。
也赞同有关 VSS 有多糟糕的评论。 以下是涵盖该主题的各种链接：
http://www.codinghorror.com/blog /archives/000660.html
http://www.developsense.com/testing/ VSSDefects.html
http://wadhome.org/svn_vs_vss.html
编辑：另请参阅:
源代码控制 - 锁定与合并？
Almost Definitely SVN. SVN sports a different way of working (Copy-Modify-Merge instead of Lock-Modify-Unlock). It's a bit of a learning curve, but it's the way things have gone for several years now, so most devs will have to learn it at some time or other anyway. Lock-Modify-Unlock is way too much of a pain, and there are serious collaboration problems that it actually contributes to, which I'd be happy to explain if you're curious.
Seconding the comments about how bad VSS is as well. Here are various links that cover the topic:
http://www.codinghorror.com/blog/archives/000660.html
http://www.developsense.com/testing/VSSDefects.html
http://wadhome.org/svn_vs_vss.html
Edit: See also:
Source Control - Lock vs. Merge?
作为经历过 VSS 的人来说 -> 对于大型代码库的 SVN 转换过程，我想说最大的好处是能够安然入睡，因为知道您的 SCM 系统不会突然出现故障而损坏您的数据库，并且您必须返回到昨天的备份。 您每天都会备份数据库，对吗？
使用 VSS，每月至少发生一次损坏。 使用 SVN（相同的硬件和操作系统）——两年多以来一次都没有。
哦，分支/合并功能真是太棒了！
Speaking as someone who went through the VSS -> SVN transition process for a large codebase, I would say the biggest benefit is being able to sleep soundly knowing that your SCM system wont suddenly have a hiccup that corrupts your database and you have to go back to yesterday's backup. You do backup your database daily, right?
With VSS, corruption happened at least once per month. With SVN (same hardware & OS) - not once in over two years.
Oh, and the branching/merging capabilities are sweet!
出于上述所有原因，当然应该选择 SVN。 你可以尝试 ankhsvn 这是一个 Visual Studio 的 svn 插件。 这样您就可以两全其美：使用 SVN，所有工作仍然在 Visual Studio 内完成。
Definitely, go with SVN, for all stated reasons above. You could try it ankhsvn which is a svn plugin for visual studio. This way you get the best of both worlds: using SVN and all work still gets done inside visual studio.
只是对 Koista Navin 的答案的补充。
他说： 这是关于这个主题的一本很棒的书：C Pilato 的 Version Control with Subversion
有一个免费的在线版本：
http://svnbook.red-bean.com/
Just an addition to Koista Navin's answer.
He said: Here is a great book on this subject: Version Control with Subversion by C Pilato
There is a free online version:
http://svnbook.red-bean.com/
Team Foundation Server 是在 .NET 世界中进行开发的最佳选择。 然而它不是免费的，对于当前的 2008 版本来说它可能相当昂贵。 如果您有更高级别的 Visual Studio 软件包，您可以免费获得 TFS 工作组版本，它允许 5 个用户访问，无需额外付费。
工作组版本有一些主要注意事项，您必须使用 TFS 服务帐户的 5 个插槽之一，除非您将其设置为在将包含在 TFS 成员列表中的用户帐户下运行。 另一个是，一旦达到 5 个用户的限制，跃升至 6 个用户的成本将相当惊人，因为当前的许可证要求包括需要为团队的每个成员购买服务器（几千美元）和 CAL。 在团队中再增加一名成员的成本相当高昂。
然而，Microsoft 已经意识到这一点，并在 2010 年改变了这一点。您将不再需要购买服务器本身，而只需要购买 CAL。 TFS 2010 服务器许可：它包含在 MSDN 订阅中
Team Foundation Server is the optimal choice for developing in the .NET world. However it is not free and for the current version 2008 it can be quite expensive. If you have higher level package for Visual Studio you do get TFS workgroup edition for free which allows 5 users access for no additional cost.
There are some major caveats to the workgroup edition you must use one of the 5 slots for the TFS service account unless you set it up to run under a users account that will be included in the TFS member list. The other is once you hit your 5 user limit the jump to 6 users is a fairly staggering cost as the current license requirements include the need to purchase the server (a few thousand dollars) AND CALs for every member of the team. That's a fairly prohibitive cost to add one more member to the team.
However, Microsoft has come to realize this and is changing this for 2010. You will no longer need to purchase the server itself and will only need to purchase CALs. TFS 2010 server licensing: It's included in MSDN subscriptions