我们应该从 svn 迁移到 Team Foundation Server 2010 吗？
我们有 6 名开发人员，目前使用带有 SVN 的 Visual Studio 2008 Professional 和 Visual SVN。 vs2010一发布，我们就会从vs2008 pro升级到vs2010 premium。
但是，如果 Team Foundation Server 在 vs2010 premium 中包含适当的源代码控制，那么使用它确实有意义。我们喜欢 SVN，但更喜欢工具的紧密集成。
在互联网上，有关 SVN 与 TFS 2010 的信息似乎很少。因此我在这里提出问题。
编辑：此视频看起来非常引人注目。这是营销言论还是真实的？
谢谢大家的回复！我非常欣赏这一点。更多背景信息。
这是我们当前的堆栈； vs2008 pro、Visual SVN、SVN、Jetbrain Teamcity。我的主要问题是我们使用了来自不同供应商的许多工具，这些工具或多或少地集成了。有时更多，大多数时候更少。至少要花很多时间才能正确设置。
我们目前不使用分支，但我们想使用。因此我们必须从头开始设置SVN（我们仔细研究了它）。那么让我重新表述一下我的问题：我们应该设置 SVN 还是开始使用 TFS？
We are with 6 developer and currently use Visual Studio 2008 Professional with SVN and Visual SVN. As soon as vs2010 is released we will upgrade from vs2008 pro to vs2010 premium.
However if Team Foundation Server has a proper source control included in vs2010 premium, then it does make sense to use it. We like SVN, but like tight integration of tools even better.
On the internet information on SVN versus TFS 2010 seems to be scarce. Hence my question here.
EDIT: This video looks very compelling. Is this marketing talk or real?
Thank you all for your replies! I absolutely appreciate this. A little more background info.
This is our current stack; vs2008 pro, Visual SVN, SVN, Jetbrain Teamcity. My main problem is that we use a lot of tools from different vendors which more or less integrate. Sometime more, mostly less. At least it takes a lot of time to set it up correctly.
We currently do not use branches, but we want to. Therefore we have to set up SVN from scratch (we looked into it carefully). So let me rephrase my question: Should we set up SVN or start using TFS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
根据我的经验，TFS 作为源代码控制服务器不是正确的选择。合并速度非常慢，签入过程违反直觉，并且通常会以锁定文件结束，只有管理员才能解锁。 SVN 更加成熟、灵活和快速。
From my experience, TFS as a source control server is not the right choice. Merges are terribly slow, check-in procedure is counter-intuitive and usually ends with locked files that only an administrator can unlock. SVN is far more mature, flexible and fast.
如果您是 Microsoft 商店，那么 TFS 非常适合。
如果 Subversion 满足了你所需要的一切，你会修复一些没有损坏的东西吗？
你必须有一个改变的理由。
[我在工作中使用 TFS，效果很好，几乎没有问题。我在家使用 Subversion，只是因为我需要更少的基础设施]。
更新[2012/05/01]：如果您不是微软商店，那么Git和mercurial现在将是首选工具。
If you are a Microsoft shop, then TFS is a good fit.
If Subversion does everything you need, would you fix something that is not broken?
You have to have a reason to change.
[I use TFS at work and it works great, with very few problems. I use Subversion at home, simply because I need less infrastructure].
Update [2012/05/01]: If you are not a Microsoft shop, then Git and mercurial would now be the tools of choice.
似乎有很多人建议改用TFS，我想走另一条路。
我从以前的工作中使用 SVN 转到最近的工作中使用 TFS。我会这样总结：
集成非常有吸引力，没有任何其他东西可以将如此多的部件集成在一起。代价是这些单独的部分中的每一个都有点糟糕。
更多细节：
源代码控制系统虽然在服务器等方面技术上非常好，但使用起来很痛苦。文件始终标记为只读，您必须明确检出它们才能编辑它们。这会让你的生活变得很糟糕，除非你 100% 的时间都使用 Visual Studio 集成...如果你正在使用 Visual Studio 集成，请记住它会将所有文件的 SCC 状态存储在 CSPROJ 文件中，所以准备好处理偶尔的混乱和失败，因为您将文件添加到了 TFS，但 Visual Studio 尚未意识到这一点（反之亦然）。
Bug 跟踪系统的搜索能力较差且有限，并且 UI 很难使用。它让我想起了很多旧的access数据库形式。与一个漂亮干净的基于网络的跟踪器相比，它是白天和黑夜的。
总体而言，大多数用户界面的可用性非常差。虽然您可以使用 TFS 完成许多事情，但速度不会很快，而且您必须单击太多组合框！
此外，TFS 与您的域具有非常紧密的集成。如果您 100% 的员工和所有构建/测试机器都在同一个域中，那么这可能没问题……但如果不是，那么这会给您带来一些痛苦。
There seem to be many people recommending the switch to TFS, I'd like to go the other way.
I moved from working with SVN at a previous job over to TFS at a more recent job. I'd summarize it like this:
The integration is attractive, and there's nothing else which has as many parts all integrated together. The tradeoff is that each of those individual parts kind of sucks.
More Detail:
The source control system, while technically very good on the server, etc, is PAINFUL to use. Files are always marked read only and you have to explicitly check them out to edit them. This makes your life awful unless you're using the visual studio integration 100% of the time... And if you are using the visual studio integration, remember that it stores the SCC status of all your files IN THE CSPROJ FILE, so be prepared to deal with occasional confusion and failure because you added the file to TFS, but visual studio hasn't realized this (or vice versa).
The bug tracking system has poor and limited search, and the UI is hard to use. It reminds me a lot of old access database forms. Compare this to a nice clean web-based tracker and it's night and day.
Overall, most of the UI's have really poor usability. While you can get many things done using TFS, it won't be quick, and you'll have to click on far too many combo boxes!
Additionally, TFS has very tight integration with your domain. If 100% of your staff and all your build/test machines are all on the same domain then this is probably fine... but if you're not, then this will cause you some pain.
SVN 进行源代码控制。它的默认客户端是命令行，但也存在 GUI 工具。
TFS 可以进行源代码控制、错误/问题跟踪、自动构建、向经理报告，并且可以治愈男性型秃发。它的默认客户端是 Visual Studio。
如果您想要的只是源代码控制，那么 SVN 就可以工作，并且为什么要更改未损坏的内容。如果您想要的只是更紧密地集成到 Visual Studio 中，请查看 Ankh 或 VisualSVN。
如果您想要自动构建、持续集成、签入策略和规则、报告、问题跟踪，并且您希望这一切都合而为一，那么 TFS 适合您 - 假设您不冒险使用 Microsoft 开发工具（通常 - 有用于其他 IDE）。您可以使用其他 FOSS 工具获得相同的效果，并用胶带将它们包裹在 SVN 上，这也有效，只是不是那么无缝并且需要更多的投资。
然而，您将源代码控制系统与开发生命周期管理工具进行比较。 TFS 可以进行源代码控制，但它的作用远不止于此。
SVN does source control. Its default client is the command line, but GUI tools exist.
TFS does source control, bug/issue tracking, automated builds, reporting for managers and can cure male pattern baldness. Its default client is Visual Studio.
If all you want is source control then SVN works, and why change what isn't broken. If all you want is tighter integration into Visual Studio then look at Ankh or VisualSVN.
If you want automated builds, continuous integration, check in policies and rules, reporting, issue tracking and you want it all in one then TFS is for you - assuming you don't venture outside of Microsoft Development Tools (generally - there are plugins for other IDEs). You can get the same thing with other FOSS tools, and wrap them together with sticky tape around SVN and that works too, it's just not as seamless and needs a little more investment.
However you're comparing a source control system to a development lifecycle management tool. TFS does source control, but it does so much more.
实际上，您应该尝试使用新的测试系统来评估它。很多人讨厌 TFS，有些人认为它不适合他们的工作方式。而且，当你必须开始购买更好版本的 VS 以获得一旦上瘾后你会想要的附加功能时，它就不那么免费了。
网络上有一些非 MS 营销人员的评论表明 TFS 并不是自 git 以来最好的东西。 Martin Fowler 的调查非常有趣（在 54 份回复中，没有人认为这项调查很棒甚至很好）。也许他的读者不像大多数开发人员那样热衷于“全生命周期”开发工具，但是，也许他们和我们其他人一样。类似的评论也有 - 包括 Forrester Research 的文章 （我读过：执行摘要，SVN 是独立 SCM 的“胜利”）
因此，仅仅因为 TFS 现在包含在 VS 中并不意味着它是最好的。在切换之前，您需要对其进行正确评估。
Really, you should try it out with a new, test, system to evaluate it. Plenty of people hate TFS and some think its not suitable for their ways of working. Also its not so free when you have to start buying the better versions of VS for the added features that you'll want once you're addicted.
There are reviews on the web that are not by MS marketeers that show that TFS isn't the best thing since git. Martin Fowler's survey for one is very interesting (of the 54 responses, not one thought it was great or even good). Maybe his readers are less keen on the 'full lifecycle' dev tools than most developers, but then, maybe they're just the same as the rest of us. Similar reviews are available - including Forrester Research's piece (which I have read: executive summary, SVN is "teh win" of the standalone SCMs)
So, just because TFS is now included in VS does not make it the best there is. You need to evaluate it properly before switching.
我在必要时使用 TFS，并且讨厌它的每一分钟。它实在是太妨碍我了，而且我要花很长时间才能远程完成任何事情。但主要是我无理性的仇恨。如果你的六个程序员中有一个像我一样，你就会遇到问题。而程序员比工具更重要。
I used TFS when I had to, and hated every minute of it. It just stood in my way too much, and it took forever to do anything remotely. But mainly it's just my irrational hate. If one out of your six programmers is like me you'll have a problem. And programmers are more important than tools.
我是一名Java开发人员，但我所有的朋友都是.Net，他们似乎都更喜欢SVN和Tortoise。 SVN 也得到开源社区的大力支持。
I'm a Java developer, but all my friends are .Net, they all seem to prefer SVN with Tortoise. SVN is well supported by the open source community as well.
我认为 TFS 非常棒。将错误跟踪和源代码控制与 Visual Studio 完全集成可以节省大量时间。在线协议不太繁琐，因此它也适合在需要时通过互联网进行工作。
还有许多其他功能也很有用，例如团队门户、统计跟踪、跟踪测试历史记录、捕获测试输出作为错误的一部分（非常方便！）等。
它们还具有对脚本、自动化的完整命令行支持构建，一个在 Visual Studio 之外使用的独立 TFS 客户端（例如非开发人员），以及与第三方工具（例如用于混合 Java/.NET 商店的 Eclipse）的可选集成。
主要缺点是价格——但如果你能负担得起，我认为这是目前最好的系统。
I think TFS is fantastic. Having bug tracking and source control fully integrated with Visual Studio is a big time saver. The on-the-wire protocol isn't too chatty, so it's also suitable for work over the Internet if/when needed.
There are many other features that are also useful, such as the team portal, statistics tracking, tracking test histories, capturing test outputs as part of a bug (very handy!), etc.
They also have full command line support for scripting, automated builds, a standalone TFS client for use outside of Visual Studio (say by non-developers), and optional integration with third-party tools such as Eclipse for mixed Java/.NET shops.
The main downside is price -- but if you can afford it, I think it's the best system out there at the moment.
如果您仅将其用于版本控制，请坚持使用 SVN。
如果您有 Linux/Java 解决方案，请坚持使用 SVN。
如果您只是 MS，并且喜欢使用工作项进行需求/错误跟踪等（我确实喜欢），请考虑迁移到 TFS，但请记住您需要为 CAL 制定预算，以便人们可以访问此信息。
如果您想要隔夜测试/CI 构建，请记住为您的构建服务器预算额外的 VS 许可证，因为 teambuild (msbuild) 无法构建 VDProjs、Intel 项目等。
另外...TFS“似乎”/“似乎”难以应对一些非常基本的事情，例如如何忽略您不想放入存储库的文件，并且它经常将文件标记为已更改，而 diff 显示为相同。
If you're only using it for version control, stick with SVN.
If you've got Linux/Java solutions, stick with SVN.
If you're MS only and you fancy using work items for requirement/bug tracking etc. (which I do like) consider the move to TFS but remember you'll need to budget for CALs so that people can access this information.
If you want overnight testing/CI builds remember to budget for extra VS licences for your build server because teambuild (msbuild) can't build a VDProjs, Intel projects etc.
also... TFS 'seems'/'appears' to struggle with some really basic things e.g. how to ignore files you don't want to put in the repository and it frequently marks files as having been changed that diff shows as being identical.
虽然这可能会帮助您做出决定；我同意米奇的观点。你必须有一个充分的理由去改变。 SVN 比 TFS 成熟可靠。另外，TFS 主要针对 Microsoft 应用程序，而 SVN 的范围远远超出了 TFS。
Though this might help you make a decision; I would agree with Mitch. You've got to have a good reason to change. SVN is way mature and dependable then TFS. Plus, the TFS is primarily targeted towards Microsoft applications, compared to the scope of SVN which is way beyond TFS.
这更多的是一个心理问题，而不是一个技术问题。
在我看来，你不应该迁移并保持简单。由于只有 6 名开发人员，您将无法完成任何复杂到足以使用 TFS2010 高级功能的一部分的事情。
VisualSVN是一个让你足够“集成”的好工具。而且还会得到更好的改善。
It's more a psychological, than a technical question.
As to my opinion, you should not migrate and keep yourself simple. Having only 6 developers, you will not get to anything complicated enough to use even a portion of high-level TFS2010 abilities.
VisualSVN is a good tool that keeps you "integrated" enough. And it will be improved even better.
我的上一个客户有 TFS，现在我的新客户有颠覆，这太糟糕了。没有架子才是真正的杀手。
我有没有提到 VS 2010 是免费的
I had TFS at my last client, now my new client has subversion and its awful. No shelving is a real killer.
Did I mention its free with VS 2010
我使用过 TFS 2010 和 SVN（带有 Tortoise）、Mingle、MediaWiki 等。
虽然 TFS 为您提供了与 Visual Studio 的源安全样式集成，但这就是优点所在。 SVN 在版本控制方面要好得多，Mingle 是一个更好的协作工具，而 MediaWiki 是一个更好的 wiki。
如果您需要测试 TFS 的主要产品作为源代码控制，请创建多个 TFS 项目，添加一些更改并尝试恢复到以前的版本。您将需要一个命令提示符工具，如果您在遵循劣质的在线说明后碰巧回滚了正确的项目，那么它看起来会很纯粹。
I've used both TFS 2010 and SVN (with Tortoise), Mingle, MediaWiki, etc.
Although TFS gives you Source Safe style integration with Visual Studio, that's where the niceties end. SVN is much better at version control, Mingle is a blindingly better collaboration tool and MediaWiki is a much better wiki.
If you need to test TFS's main offering as source control, then create several TFS projects, add some changes and try reverting to a previous version. You'll need a command prompt tool and it'll be sheer look if you happen to rollback the correct project after following the shoddy online instructions.
在我工作的地方，团队主要是为了满足需求、规范等而从 DOORS 迁移到 TFS。他们仍然使用 Perforce 作为存储库。我使用过大多数存储库，每个存储库都有自己的怪癖。
回答你的问题——你想要解决的问题是什么？您是否需要一个集成的解决方案来管理您的文档、错误、源代码控制？ TFS 为您提供集成部分，以便您每次签入代码时都可以将其标记回错误、需求或规范。如果您的公司使用大量流程，那么这是一个很棒的功能。在我看来，你是一家小商店，你真的不需要那种流程。我会坚持使用有效的方法，直到你变得更大并且你的需求发生变化。
Where I work, have the group is migrating over to TFS from DOORS mainily for requirements, specifications, etc. They still use Perforce as the repository. I have used most of the repositories out there and each one has there own quirks.
To answer your question - what is the problem your trying to solve? Do you need a integrated solution to manage your documents, bugs, source control? TFS gives you the integration portion so that each time you check in code you can tag it back to a bug, a requirement, a specification. That is a great feature if your company uses a lot of process. Sounds like to me that your a small shop and you really don't need that kind of process. I would stick with what works until you grow bigger and your needs change.