我是一家有点小的创业公司。现在我们正在使用JEDI VCS来满足我们的源代码控制需求，除了它的错误外，这也不算太糟糕。它起作用是因为我们用它来管理“旧的”Delphi项目。
现在，我们正在开发VS 2008和.NET中的东西，当我尝试分支项目并且必须提供时，我意识到JEDI与Delphi密切相关。< / p>
现在。我认为SVN听起来不错，但我已经使用它大约3年了，我很满意它，所以我不想因为我知道而选择它。 我的老板想要Sourcesafe。在阅读了互联网上的所有“为什么永远不会使用VSS”之后，我认为它看起来很糟糕，并且仍然无法解决当前我们正在分支的问题（因为VSS是分支的地狱）。他希望我们使用VSS，因为它可以对SQL数据库进行源代码控制（显然？我从来没有能够让它工作，并且听说它需要一些单独的Web开发版本等。 现在，我们应该使用什么源代码控制（它不到5个程序员），这是现代的，便宜/免费的？我怎么能说服我的老板说它不能进行SQL版本控制，或者它不值得呢？
答案 0 :(得分：8)
Subversion，使用它> 5年。加入TortoiseSVN前端，它非常棒。
VSS是垃圾。它在结账时锁定文件（我个人讨厌），它不是免费的。您需要一个单独的GUI。任何类型的慢带宽管道都非常糟糕。免责声明：我在VSS的经历已超过5年。
关于分支/合并有些人推荐使用linux团队使用的git，而不是自己使用它，所以无法评论。
答案 1 :(得分：6)
不惜任何代价避免使用VSS（我已经使用了4年）。它是旧的，不受支持（这通常是管理者的神奇短语;））。它的回购容易出错。这是糟糕的坏事。
SVN很好并且尝试过。它有很多文档和工具（包括免费Visual Studio integration）。
目前的趋势是使用分布式VCS，例如Mercurial和Git。想法是为每个开发人员提供他自己的回购，他可以用主回购提交，开发人员稍后“推”他们的更改。 Mercurial有很好的Windows工具（包括免费VS plugin），git有一个更差的AFAIK，但它肯定会改变。
所有这些都不会自动存储数据库方案，但可以在开发过程中强制执行此操作，方法是将方案保存在文件中并将其提交到repo。
答案 2 :(得分：5)
强烈推荐Git，Mercurial和Bazaar。
Mercurial基本上是Git的一些小的实现更改，以及一个纯python实现，这意味着你可以将mercurial与脚本紧密结合。
为什么我为我们的工作场所选择mercurial上面的git是因为对于一个新人来说，这更加简单。一个命令。
我自己没有使用过Bazaar，但我读到它非常好。
如果您正在考虑SVN，因为“我不需要分布式部分”：现代VCS不仅分布式，而且功能更加优雅。他们被认为是正确的。
SVN在其实现中存在很多问题，包括每个项目文件夹中的杂乱.svn子文件夹，所以基本上如果你只是mv folder1 folder2，你就注定了SVN。
如果你不习惯unix方式，我强烈推荐Mercurial，它很容易上手。
BTW不接受我的话，看看这个讲话： http://www.youtube.com/watch?v=4XpnKHJAok8答案 3 :(得分：2)
好的，他决定我可以尝试任何我想要的东西。如果它工作正常，那么他现在没有问题，因为我得到了数据库备份。所以我想我会尝试颠覆，因为它会变得轻而易举......
答案 4 :(得分：1)
在我看来，对于小规模和易用性，svn是你最好的选择。它有很棒的ui工具，效果很好。
但是：
如果您愿意进行一些学习，分布式版本控制很快就会成为开发人员的首选工具。
即使您不是在分布式环境中开发，分布式源代码控制系统的设计也非常适合单独工作的个人和个人协作。
大多数分布式版本控制系统也比svn更好地处理合并和分支，因为这些操作对于分布式版本控制来说是如此基础，但净效果对每个人来说都更好。
我建议git（msysGit在Windows上），mercurial（TortoiseHg制作一个出色的资源管理器插件），Fossil作为一个非常棒的轻量级替代品。
答案 5 :(得分：1)
由于您已使用SVN 3年，您认为您没有足够的数据来说服您的经理使用SVN吗？在这里获取有关VSS的详细信息并向他显示比较结果。
答案 6 :(得分：0)
我不会权衡VCS的选择，但我们为SQL版本控制所做的是每天三次自动编写所有数据库对象的脚本，然后检查它。你可以脚本来分隔每个数据库的文件，或每个对象或其他任何单独的文件。开发中的数据库更改并不总是与特定功能分支相关联 - 它们通常是从单独的开发DBA视角驱动的，可以满足多个开发人员的需求，并且通常不会被回滚或合并或者其他任何东西。
我们也为生产服务器执行此操作，但生产更改通常包括性能调整和管理任务的参数更改。
我们使用命令行Apex SQL Script - 它实际上支持一些VCS系统。
数据库专业人员的团队系统（所谓的数据dude）支持复杂的数据库版本控制/部署系统，当然，它还包括完整的版本控制，如Team System的其余部分。我的理解是，2010版本应该具有SourceSafe定价级产品 - 不确定该SKU是否包含任何数据库功能。
答案 7 :(得分：0)
在商业环境中必须提出的一个重要问题是，“如果我们遇到困难/某些事情会变得混乱，谁会支持我们？”。大多数开源VCS被许多组织广泛使用，包括商业和非商业，并且有大量免费（和付费）资源可以帮助您。书籍，网站，顾问等。如果你想深入挖掘自己，你也有源头。有许多第三方工具可以扩展它们的功能，例如代码审查和缺陷跟踪系统。如果你想坚持使用商业解决方案，一些商业VCS（特别是Perforce）也有广泛的用途，并且有很好的支持。
有趣的是，我听说过VSS的恐怖故事比其他所有VCS都要多。这也不是出于纯粹的微软仇恨。
根据您商店的开发实践，您可能不会出现“三巨头”之一：Subversion，Mercurial和git。
答案 8 :(得分：0)
为了回答你的老板认为svn不是很好，因为你无法控制数据库，我们的数据库对象都是源代码控制，因为除了通过脚本，我们不允许任何人对数据库进行任何操作。由于开发者没有产品权利，他们遵循这个规则或者他们的东西无法部署。
答案 9 :(得分：0)
如果符合以下情况，我会调查Team Foundation Server：
当然，它适用于Visual Studio，而且成本可能很高。如果您在美国并从事WebDev，您可以通过WebSpark激励计划获得3年免费的开端。 作为额外的奖励，它与TeamCity和Cruise Control完美结合。工作项可以与您的工件绑定并与MS Project集成 它可能是初创公司的一大产品，但如果您打算在不久的将来使用它，我建议您寻找它在流程管理领域带来的好处。
答案 10 :(得分：0)
我的论点是从SVN开始。这不是一辈子的承诺，因为它是免费的 - 如果它真的不能满足您的需求只需切换。
这些天你更有可能找到熟悉SVN的人，几乎任何人都能够管理它。
我让队友们对每个版本控制系统都很不满意。我听说SVN比其他人少。我听到更多关于像VSS和P4这样的大老玩家的婊子。
我几乎使用了所有这些，而且我从来没有真正抱怨过svn。小型项目，大型项目 - 甚至可以直接扩展到分布式版本控制系统。