适合我们使用的最佳源代码控制（以及如何说服人们相信它？）
我在一家小型初创公司。现在我们正在使用 JEDI VCS 来满足我们的源代码控制需求，除了有问题之外，这还算不错。它之所以有效，是因为我们用它来管理“旧”Delphi 项目。
现在，我们正在 VS 2008 和 .NET 中开发东西，当我尝试分支项目并且必须提供 Delphi 项目文件时，我意识到 JEDI 与 Delphi 密切相关。
现在那么。我认为 SVN 听起来不错，但我已经使用它大约 3 年了，并且对它很满意，所以我不想仅仅因为我了解它就选择它。
我的老板想要 Sourcesafe。在阅读了互联网上所有“为什么永远不要使用 VSS”的内容后，我只是觉得用它来开发看起来很糟糕，而且仍然无法解决我们当前面临的分支问题（因为 VSS 对于分支来说是地狱）。他希望我们使用 VSS，因为它可以对 SQL 数据库进行源代码控制（显然？我从来没有能够让它工作，但听说它需要一些单独的 Web 开发版本或其他东西。
那么，什么源代码控制我们应该使用现代且便宜/免费的（少于 5 名程序员）吗？我怎样才能说服我的老板它不能进行 SQL 版本控制，或者它不值得？
I'm in a little bitty startup company. Right now we are using JEDI VCS for our source control needs, which isn't too bad except for it's buggy. It worked because we were using it to manage "old" Delphi projects.
Now, we are developing things in VS 2008 and .NET and I realized JEDI is extremely tied to Delphi when I went to try to branch a project and an Delphi project file must be provided.
Now then. I'm thinking SVN sounds pretty good, but I've been using it for about 3 years now and am comfortable with it, so I don't want to choose it just because I know it.
My boss wants Sourcesafe. After reading all the "Why to never use VSS" stuff on the internet I just think it looks hellish to develop with, and still will not fix the current problem we are at which is branching(since VSS is hell for branching). He wants for us to use VSS though because it can do source control on SQL databases(apparently? I've never been able to get it to work though and heard it required some separate web develop edition or something.
Now then, what source control should we use(it's less than 5 programmers) that is modern and cheap/free? And how can I convince my boss either that it can't do SQL versioning, or that it's not worth it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
Subversion，使用时间超过 5 年。添加 TortoiseSVN 前端，效果非常好。
VSS就是垃圾。它在结账时锁定文件（我个人讨厌这一点），它不是免费的。您需要一个单独的 GUI。在任何类型的慢速带宽管道上，这确实是可怕的。免责声明：我使用 VSS 的经验已经超过 5 年了。
关于分支/合并，有些人推荐 git，由 linux 团队使用，我自己没有使用过，所以无法发表评论。
Subversion, used it for >5 years. Add in the TortoiseSVN front end and it's pretty damn good.
VSS is rubbish. It locks files on checkout (which I hate personally), it isn't free. You need a separate GUI. It is truly awful across any sort of slow bandwidth pipe. Disclaimer: My experiences with VSS are over 5 years old.
On branching/merging some people recommend git, used by the linux team, not used it myself so can't comment.
不惜一切代价避免使用 VSS（我已经使用它 4 年了）。它很旧并且不受支持（这通常是管理者的神奇短语；））。它的存储库很容易出错。这是坏-坏-坏。
SVN 很好并且经过尝试。有很多相关文档和工具（包括免费的 Visual Studio 集成）。
当前的趋势是使用分布式 VCS，例如 Mercurial 和 Git。想法是为每个开发人员提供自己的存储库，他可以将其与主存储库一起提交，开发人员稍后“推送”他们的更改。 Mercurial 有很好的 Windows 工具（包括免费的 VS 插件），据我所知，git 有一个更差的工具，但它会肯定会改变。
所有这些都不会自动存储数据库方案，但是可以通过将方案保存在文件中并将其提交到存储库来在开发过程中强制执行此操作。
Avoid using VSS at any cost (I've used it for 4 years). It is old and unsupported (this is usually a magic phrase for managers ;)). It's repos are prone to errors. It is bad-bad-bad.
SVN is nice and tried. There's a lot of documentation and tools for it (including free Visual Studio integration).
Current trend is to use distributed VCS, such as Mercurial and Git. Idea is to provide each developer with its own repo which he can commmit with main repo where developers later 'push' their changes. Mercurial has good windows tools (including free VS plugin), git has worse one AFAIK, but it will surely change.
All of them don't store DB scheme automatically, but this can be forced in your development process by saving your scheme in a file and committing it to repo.
强烈推荐 Git、Mercurial 和 Bazaar。
Mercurial 基本上是 Git，只是做了一些小的实现更改，并且是纯 python 实现，这意味着您可以将 Mercurial 与脚本紧密结合起来。
为什么我在工作场所选择 Mercurial 而不是 git 是因为它对于新人来说更容易上手。一声令下。
我自己没用过Bazaar，但我读到它非常好。
如果您考虑使用 SVN 是因为“我不需要分布式部分”：现代 VCS 不仅是分布式的，而且在功能上更加优雅。它们是经过深思熟虑的。
SVN 在它的实现中存在很多问题，包括每个项目文件夹中凌乱的 .svn 子文件夹，所以基本上如果你只是 mv 文件夹 1 文件夹 2，你就注定无法使用 SVN。
如果您不太习惯 unix 方式，我强烈推荐 Mercurial，它非常容易上手。
顺便说一句，不要相信我的话，看看这个演讲：
http://www.youtube.com/watch?v=4XpnKHJAok8
Git, Mercurial and Bazaar come highly recommended.
Mercurial is basically Git with some small implementation changes, and a pure python implementation, which means you can closely tie in mercurial with scripts.
Why I choose mercurial above git for our workplace is because it's a lot simpler for a new person to pick up. One command.
I haven't used Bazaar myself, but I read it's very nice.
If you're considering SVN because "I don't need the distributed part": the modern VCSes are not only distributed, but much much more elegant in functionality. They are thought out properly.
SVN has a lot of issues in it's implementation, including the messy .svn subfolders in every project's folder, so basically if you just mv folder1 folder2, you're doomed with SVN.
If you're not too used to the unix way, I'd highly recommend Mercurial, it's very easy to pick up.
BTW don't take my word for it, have a look at this talk:
http://www.youtube.com/watch?v=4XpnKHJAok8
好吧，他决定我可以尝试任何我想做的事情。如果它工作得很好，那么既然我已经进行了数据库备份，那么他就不会遇到任何问题。所以我想我会尝试颠覆，因为它运行起来会很容易。
Ok, He's decided I can try whatever I want to. If it works decently, then he doesn't have a problem with it now that I got the database backups going. So I think I'll try subversion simply because it'll be a breeze to get running..
在我看来，对于小规模和易用性来说，svn 是最好的选择。有很棒的 ui 工具，而且效果很好。
但是：
如果您愿意做一些学习，分布式版本控制很快就会成为开发人员的首选工具。
即使您不是在分布式环境中进行开发，分布式源代码控制系统的设计也非常适合单独工作的个人和协作的个人。
大多数分布式版本控制系统在处理合并和分支方面也比 svn 好得多，因为这些操作对于分布式版本控制来说非常基础，但最终效果是它对每个人都更好。
我推荐 git (msysGit（Windows 上）），mercurial ( TortoiseHg 是一个很棒的浏览器插件），并且 Fossil 作为一个很棒的轻量级替代品。
in my opinion for small scale and ease of use, svn is your best bet. There are great ui tools for it, and it works well.
HOWEVER:
If you are willing to do a little learning, distributed version control is quickly becoming a tool of choice for developers.
Even if you are not developing in a distributed environment, the design of distributed source control systems is a natural fit for individuals working alone and for individuals collaborating.
Most distributed version control systems also handle merging and branching much better than svn, because those operations are so fundamental to distributed version control, but the net effect is it's better for everyone.
I'd recommend git (msysGit on windows), mercurial (TortoiseHg makes a great explorer addin), and Fossil as an awesome lightweight alternative.
既然您已经使用 SVN 3 年了，您不认为您有足够的数据来说服您的经理使用 SVN 吗？在此处获取有关 VSS 的详细信息并向他展示比较。
Since you have used SVN for 3 years don't you think that you have enough data to convince your manager to use SVN? Get details about VSS here and show him the comparison.
我不会权衡 VCS 的选择，但我们对 SQL 版本控制所做的就是每天对所有数据库对象执行 3 次自动脚本编写，然后签入。您可以编写脚本来为每个数据库单独的文件，或单独的文件每个对象的文件或其他什么。开发中的数据库更改并不总是与特定的功能分支相关 - 它们通常是从单独的开发 DBA 角度出发，满足多个开发人员的需求，并且通常不会回滚或合并或其他任何情况。
我们也对生产服务器执行了此操作，尽管生产更改通常包括性能调整和管理任务的参数更改。
我们使用了命令行 Apex SQL 脚本 - 它实际上支持一些 VCS 系统。
面向数据库专业人员（所谓的数据家伙）的 Team System 支持复杂的数据库版本控制/部署系统，当然，它还包括像 Team System 的其他部分一样的完整版本控制。据我了解，2010 版本应该有 SourceSafe 定价级别的产品 - 不确定该 SKU 是否包含任何数据库功能。
I won't weigh in on the choice of VCS, but what we did for SQL version control was to do automated scripting of all database objects three times a day and then check that in. You can script to separate files per DB, or separate files per object or whatever. The database changes in development were not always tied to a specific feature branch - they are usually driven from a separate development DBA perspective working with multiple developer's needs, and typically aren't ever going to be rolled back or merged or whatever.
We also did this for production servers, although production changes usually consisted of performance tweaks and parameter changes to administrative tasks.
We used the command-line Apex SQL Script - it actually supports some VCS systems.
Team System for DB professionals (so-called data dude) supports a sophisticated DB versioning/deployment system, and of course, it also includes complete version control like the rest of Team System. It is also my understanding that the 2010 version is supposed to have a SourceSafe-pricing-level product - not sure whether that SKU will contain any database functionality.
在商业环境中必须提出的一个重要问题是，“如果我们陷入困境/出现问题等，谁会支持我们？”。大多数开源 VCS 被许多组织（商业组织和非组织）广泛使用，并且有大量免费（和付费）资源可以为您提供帮助。书籍、网站、顾问等。如果您想自己深入挖掘，您也有来源。有许多第三方工具可以扩展它们的功能，例如代码审查和缺陷跟踪系统。如果您想坚持使用商业解决方案，一些商业 VCS（尤其是 Perforce）也有广泛的使用，并且有良好的支持。
有趣的是，我听过的关于 VSS 的恐怖故事比所有其他 VCS 的总和还要多。这也并非纯粹出于对微软的仇恨。
根据您商店的开发实践，您可能会选择“三巨头”之一：Subversion、Mercurial 和 git。
One important question that must be asked in a commercial setting is, "who will support us if we get stuck / something goes haywire / etc.?". Most of the open source VCS are widely used by many organizations, both commercial and non-, and have a wealth of free (and paid) resources available to help you. Books, websites, consultants, etc. You also have the source, if you want to dig deeply on your own. There are lots of third party tools that extend the functionality of them, like code review and defect tracking systems. Some commercial VCS (particularly Perforce) also have widespread use, and have decent support, if you want to stick with a commercial solution.
Anecdotally, I've heard more horror stories about VSS than all other VCSs combined. That's not out of pure Microsoft hatred, either.
Depending on your shop's development practice, you probably can't go wrong with one of the "big three": Subversion, Mercurial, and git.
为了回答你的老板认为 svn 不够好，因为你无法对数据库进行源代码控制，我们的数据库对象都在源代码控制中，因为除了通过脚本之外，我们不允许任何人对数据库进行任何操作。由于开发人员没有产品权利，因此他们必须遵守此规则，否则他们的东西将无法部署。
In answer to your boss' belief that svn is not as good because your can't source control the database, our database objects are all in source control becasue we allow no one to to anything to the db except through scripts. Since devs don't have prod rights, they follow this rule or their stuff can't be deployed.
我的观点是从 SVN 开始。这并不意味着它必须是终生的承诺，因为它是免费的——如果它确实不适合您的需求，只需切换即可。
如今，您更有可能找到熟悉 SVN 的人，并且几乎任何人都能够管理它。
我的队友们对每一个版本控制系统都抱怨不已。与其他人相比，我对 SVN 的了解较少。我听到更多关于 VSS 和 P4 等大型旧产品的抱怨。
我几乎都用过它们，而且我从来没有真正抱怨过 svn。小项目、大项目——它甚至可以直接扩展到分布式版本控制系统。
My argument would be to start with SVN. It's not like it has to be a lifetime commitment since it's free--if it really doesn't suite your needs just switch.
You are more likely to find people familiar with SVN these days and almost anyone is able to manage it.
I've had teammates bitch about EVERY version control system. I hear less about SVN than the others. I hear MORE bitching about the big old ones like VSS and P4.
I've used just about all of them, and I've never had a real complaint about svn. Small projects, large projects--it even scales directly to a distributed version control system.
如果满足以下条件，我会考虑 Team Foundation Server：
当然，它可以与 Visual Studio 配合使用，并且前期成本可能会很高。如果您在美国从事 WebDev，您可以通过 WebSpark 激励计划获得 3 年免费领先优势。
作为一个额外的好处，它可以与 TeamCity 和 Cruise Control 很好地集成。工作项目可以与您的工件绑定并与 MS Project 集成。
对于初创公司来说，它可能是一个大产品，但如果您打算在不久的将来使用它们，我建议您寻找它在流程管理领域带来的好处。
I'd look into Team Foundation Server if:
Of course, it works with Visual Studio and the cost can be steep upfront. If you are in the US and doing WebDev, you can get a 3 years free headstart with the WebSpark incentive program.
As an added bonus it integrates well with TeamCity and Cruise Control. Work items can be tied to your artifacts and integrated with MS Project.
It might be a big product for a startup but I suggest you look for the benefits it brings in the process management area if you intend to use them in the near future.