我在Visual Studio / .NET商店工作，该商店仍在使用VSS 2005进行源代码管理。我们正在寻求升级到VS Team Foundation Server并使用它的源代码控制系统，但我很好奇这是否真的是最好的选择。 StackOverflow的创建者使用Subversion，但评论说将代码叉合并回主产品很麻烦（在播客＃52中讨论）。 Joel提到Mercurial用于Fog Creek。知道Joel是一个软件势利者并且他选择Mercurial而不是Microsoft的任何东西，我想我会向StackOverflow观众提出问题：哪个源代码控制产品最适合 Visual Studio 开发人员？< / p>
答案 0 :(得分：18)
我们长时间仅使用TortoiseSVN从VSS切换到SVN。最近我们开始使用VS的VisualSVN插件（遗憾的是不是免费的）。
我必须说，在克服了VS中没有源代码控制集成的初始痛苦之后，我真的很喜欢我对所有源代码控制操作的控制级别。我强烈推荐这条路线。
如果你使用Subversion并且必须具有源代码控制集成，我强烈推荐使用VisualSVN。
如果您想尝试使用SVN，可以安装非常免费（且非常容易设置）的VisaulSVN Server产品，并在Windows服务器上运行几分钟即可运行SVN。
答案 1 :(得分：11)
我的建议是SourceGear Vault。它足够接近Visual Source（un）Safe立即感觉“舒适”，它坚如磐石（基于SQL Server，它也解决了你的备份麻烦），它非常可靠，对分支和合并有很大的支持 - 所有好东西。
对于最多2个开发人员而且对于大型团队而言价格合理的团队是免费的 - 比团队系统少得多（当然，它只是一个源代码控制 - 而不是整个团队开发系统）。我们将它与Fogbugz bug和问题跟踪器一起使用，并且这个组合放弃了我们需要的所有砰砰声，而且还要少得多。
强烈推荐。
马克
答案 2 :(得分：10)
似乎你想要VS集成，但我质疑其原因。
良好的源代码控制产品具有的功能远远多于VS集成。
你可以让subversion与VS（Ankh svn和visualsvn）集成，我也使用vault这是稳定的并与VS集成但是我使用源代码控制来处理其他事情不仅仅是与工作。
所以我更喜欢使用产品中的源代码控制。你应该试一试。
答案 3 :(得分：10)
我曾与VSS，CVS，SVN和TFS合作过。
VSS：跳过它。我失去了太多的变化，实际上已经消失了。
CVS：很好的解决方案。有一个功能SVN丢失，可视化合并。
SVN：很棒的解决方案。如果需要，可以使用加载项进行集成。我只有一个抱怨：分支之间的合并可能会更好。但是，该产品是轰炸机，非常实惠。
TFS：我工作的地方，他们并没有做太多的事情。他们只使用了源代码控件。我很高兴使用它，特别是搁架，但我无法将更改合并到分支。我想说VSS应该是什么。有时候MS会为你做的事情太费力了，你必须自己做。用户界面也不直观。所以，我坚持使用SVN。虽然，新的开源标准似乎是GIT（但不能评论它）。
答案 4 :(得分：6)
来自VSS 任何系统将是一项改进; - ）
Perforce可能是我用过的最好的主流工具。 Rational Apex甚至更好，但除非你在写Ada，否则信息对你没用。
ClearCase非常强大，但我发现它很难使用（诚然，我只用了几个星期，所以我可能没有给它一个公平的试验）。
对于成本（免费）SVN非常好。 Tortoise shell加载项使其在Windows中使用起来非常方便。
EDIT。
我看到我刚从这个古老的答案得到了支持:-)这让我重新审视，我发现我需要更新我的答案。
我现在在工作中使用TFS而且我非常喜欢它，它可能是一个大型的野兽并不适合家庭项目，但它是一个商业工具，值得一看，如果你真的重视VS集成。我确信Perforce和Clear Case也是很棒的产品，但我现在已经脱离了这些产品。
对于小型项目或家庭个人工作，我现在使用Git。我并不特别关心VS集成，我只是从命令行使用它，但在家里我在几个不同的环境之间切换，所以VS集成不是优先考虑。
答案 5 :(得分：5)
源代码管理仅是VS Team Foundation Server的 部分，它是一个完整的项目管理系统。
我同时使用了SVN和TFS，它们都比VSS更稳定，更强大。
答案 6 :(得分：3)
我和Ankhsvn一起好运。我可以与TortoiseSVN交替使用它，它可以很好地与Visual Studio和项目布局紧密集成。
答案 7 :(得分：3)
我们在工作中使用plasticscm，它不太为人所知，但很好地集成到VS中，你有自己内部的所有选项和图表。
答案 8 :(得分：2)
SVN比VSS更好，更快。我们2年前从VSS切换到SVN，因为VSS位于纽约的服务器上，VSS上的操作对于印度的开发人员来说似乎太慢了。 SVN速度更快，因为它适用于WAN而不是用于LAN的VSS。 Refer this link
您可以使用Windows资源管理器执行SVN操作，也可以使用AnkhSVN从VS.Net IDE执行SVN操作。
如果您发现以后将它们合并为hazzle，则可以在编辑之前更喜欢锁定文件。但恕我直言合并真的不是很痛苦，因为在你继续合并之前，你会看到你和你的同事代码之间的明显区别。
可以在堆栈溢出时找到SVN的优点here。
答案 9 :(得分：2)
+1忘记VS集成。
许多最好的源代码控制工具都有很棒的命令行界面。我一直很乐意使用Git for VS项目近一年。缺点是Git需要一个bash shell，它不是Windows友好的。我愿意支付没有VS集成的“成本”，以获得让生活变得更加轻松的所有高级功能。
我建议您尝试Mercurial。
我必须补充一点，这个建议更适合个人选择源代码控制。如果您正在为拥有大量开发人员的大公司寻找源代码管理标准，我会采用更为“标准”的选择，如Team System，SVN或Vault。
答案 10 :(得分：2)
我更喜欢TFSVC，因为它与Team Foundation Server中的所有其他服务集成在一起。但这取决于你想做什么。如果你想要一个ALM解决方案，这就是你要走的路。我可以设置签入策略，集成构建以及与工作项相关联。我喜欢它的分支和合并方式。我可以让我的测试人员提交与TFSVC中的代码相关的错误工作项。我有可追溯性，可以查看谁正在检查并破坏构建。我可以运行报告并获得对项目的良好可见性。一切都在一起工作。
我希望这会有所帮助。
约翰
答案 11 :(得分：1)
我们使用金库，它很好。但是如果你能从微软那里得到它，那就使用Team System。他们知道如何处理自己的问题/错误/思考方式。
答案 12 :(得分：1)
这取决于您是在寻找免费版还是商业版控制系统。
颠覆
使用Subversion，您可以使用优秀的免费开源ankhsvn插件，将Subversion与Visual Studio集成。整合非常棒！
Mercurial
如果您需要分布式版本控制，请选择带有Mercurial插件的VisualHG。 Mercurial与Git签订了合同，使用本机Windows支持开发，并且Visual Studio集成也更好。
PlasticSCM
我见过的最好的Visual Studio集成有PlasticSCM，这是PlasticSCM是windows-background版本控制系统的简单结果。它的效果非常好。
答案 13 :(得分：1)
我无法相信没有人提到过Assembla！它可以免费使用无限存储库，无限用户和1GB空间！
答案 14 :(得分：0)
我的投票是针对TFS。 VSS不仅仅是一种痛苦。我在VS之外使用了SVN，我必须看到它与它一起工作。
使用产品中的源代码管理？听起来比工作更多的工作。仅仅因为它与VS集成并不意味着你不能将它用于其他事情。如果我在VS中，我想留在那里，而不必转到另一个客户端应用程序来获取我的源代码。我喜欢VS可以直接退房。
答案 15 :(得分：0)
也许您应该问自己什么scm最适合您的项目。
我喜欢svn因为它的自由和一种标准（也许有点大胆的说）。
答案 16 :(得分：0)
我在工作中同时使用Vault和TFS。我们使用VSS而其他人遇到了问题，因此当时的领导决定切换到Vault。我没有与Vault有任何问题，但其他人有一些与合并和分支。
我开始使用TFS试用版和Vault一样喜欢它。我还没有使用许多附加功能，例如bug和工作项目跟踪，但计划。
由于您没有提及成本而且comapny已经考虑转向TFS，我认为这将满足您的需求，使产品比VSS更好，并允许您在未来成长为它。
答案 17 :(得分：0)
我使用 Visual Source Safe （2005），我不推荐它。作为基于文件文件的解决方案会导致存储库更容易被破坏的风险。我已经使用了 Source Off-Site 一个SourceGear产品，它可以通过互联网实现远程VSS签到和结账，并且运行良好，但仍有缺点，它是建立在VSS和平面文件架构。
SourceGear还会使 Vault 成为我首选的解决方案。它是基于SQL Server的存储库，因此它不受Windows文件系统问题的影响。可以像任何其他SQL Server数据库一样配置还原和备份，并且可以还原到某个时间点，而不仅仅是上次备份日期。
我还使用了 Source Anywhere （版本2.2），我发现它与VSS和Vault相比缺乏功能。但它是一个SQL Server解决方案，使备份更可靠。
我有兴趣尝试 Subversion ，如果有一个版本的Subversion使用SQL Server作为存储库，我认为这将是一个合理的解决方案。如果您在另一个操作系统上运行，Subversion可能是您的最佳选择，但如果您在Windows Server上运行，我会推荐一个SQL Server解决方案。
