我应该考虑 Subversion 之外的版本控制系统吗？
去年我对颠覆上瘾了。 我是唯一的开发人员，我也从事一些自己的项目。 使用 SVN，管理一切真的很容易 - 而且因为它通过 HTTPS 托管在在线服务器上，所以我可以从任何地方访问我的代码。 它也非常适合将代码部署到我们的生产/开发服务器。
我的观点是，它可以满足我需要它做的一切，并且从未让我失望过。
有更好的吗？ 我是否缺少其他产品中的某些功能，我可以使用这些功能来让我的生活更轻松？ 我总是致力于使用最好的软件，并且毫无问题地迁移到新技术。
我听说过GIT并且做了一些研究。 我打算尝试一下，但是当我搞乱它时，是否还有其他被认为是“行业标准”的源代码控制系统，并且它们做得比 SVN 更好吗？
Within the last year I have become addicted to subversion. I am an only developer and I also work on a few of my own projects. With SVN its really easy to manage everything - and because it is hosted on an online server though HTTPS I can access my code from anywhere. It is also great for deploying code to our production/development servers.
My point is that it does everything that I need it to do and has never failed me.
Is there anything better? Am I missing some feature in another product that I could be using to make my life easier? I am always all about using the best software out there and have no problem migrating to new technologies.
I have heard of GIT and have done some research. I plan on giving that a try but while I am messing with that, are there another other source control systems that are considered "industry standard" and do they do things better then SVN?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
如果 SVN 满足了您的所有需求，那么我看不出进行更改的原因。
如果好奇心是您寻求不同源代码控制的驱动力，那么我建议您阅读有关 git 或其他分布式 scm 解决方案的内容，并尝试弄清楚是否值得进行投资以进行切换（我怀疑这是否适合您的情况）。
If SVN addresses all of your needs then I don't see the reason for change.
If curiosity is the driver of your quest for a different source control then I would recommend reading about git or other distributed scm solution and try to figure out if it's worth the investment in order to switch (which i doubt it is in your situation).
Git、Mercurial 和 Bazaar 都是分布式控制系统，其运行理念是您并不总是连接到网络，并且不需要有一个中央版本的存储库。
如果您正在进行大量独立工作（有时称为“飞行模式”），例如您在飞机上且无法投入工作，请看看 Bazaar。 我发现它比 Git 或 Mercurial 更容易适应。
如果您始终从事与网络相关的工作，并且您是唯一的开发人员，那么您可能可以坚持使用 Subversion。
另外，请考虑在 Subversion 中保留主目录的价值。
Git, Mercurial and Bazaar are distributed control systems that operate of the idea that you aren't always connected to the Net, and that there need not be one central version of the repository.
If you're doing a lot of detached work, sometimes called "airplane mode", as in you're on an airplane and can't commit, take a look at Bazaar. I've found it easier to acclimate to than Git or Mercurial.
If you're always doing work connected to the Net, and you're the only developer, then you can probably stick with Subversion.
Also, please consider the value of keeping your home directory in Subversion.
Mercurial
我主要使用了CVS和SVN，很高兴也很满足，然后我开始研究分布式源代码控制，因为DSVC有很多大惊小怪。 使用 DSVC 后，我注意到我的开发风格发生了变化，我变得更加流畅、适应性更强。 让我可以轻松地合并回主干或实验分支。
Git
Git 很酷，但您需要不断维护源代码 depo 并重新打包它。
由于它由许多 bash 脚本组成，因此在 Windows 上运行时遇到问题。
但它的速度非常快，有许多功能供您使用。 实际上，功能的数量可能是一个缺点。
BZR
自从我开始使用HG以来，我就没有回头过
Mercurial
I mainly used CVS and SVN, happy and content, then I started researching Distributed Source control as there was lots of fuss made about DSVC. After a using DSVC I noticed a change in my development style, I became more fluid and adaptable. Allowing me to merge back into trunk or experimental branch painlessly.
Git
Git is cool, but you need to constantly maintain your source code depo and repack it.
As it consists of many bash scripts it has trouble running on windows.
But it is blazingly fast, with many features for you to use. Actually the amount of features can be a disadvantage.
BZR
I havnt looked back since I started with HG
我个人会继续使用 Subversion。 从专业的角度来看，我看到更多的工作要求（并且知道）Subversion 与 GIT 的比较。 此外，还有许多围绕 Subversion 构建的开源和免费软件工具，更不用说 Subversion 庞大的社区了。
源代码控制并不总是关于最新和最好的，但更多时候是关于经过尝试和真实的。
I personally would stay with Subversion. From a professional stand point I have seen a lot more jobs ask for (and know) what Subversion was compared to GIT. Also there are a lot of open source and freeware tools built around Subversion, not to mention Subversion's huge community.
Source control is not always about the latest and greatest, but is more often about what is tried and true.
改变的最好理由是必要性。 然而，听起来似乎没有真正需要改变。 您是一支“一军”，因此大多数强大的功能不适用于您的情况。 是的，人们会在这个问题上与我争论，但是他们会推动这个或那个你很可能真正不需要的功能。 时机就是一切，如果将来您的需求发生变化，那么就改变您的解决方案。
对于问题空间，总会有更好或不同的解决方案，在这种情况下是源代码控制，但是您应该平衡个人发展、流程/实践改进和交付工作产品。 您可以了解有关源代码控制的不同解决方案/应用程序的更多信息，以扩展您的知识，以识别何时需要切换解决方案，但坚持目前有效的解决方案。
The best reason to change is necessity. However, it sounds like there is no real need to change. You are an "Army of One" so most of the powerful features do not apply to your situation. Yes, people will argue with me on this, however they will be pushing this feature or that feature which more than likely you really do not need. Timing is everything, if in the future your needs change then change your solution.
There will always be better or different solutions for a problem space, in this case source control, however you should balance personal development, process/practice improvements, and delivering work product. You could learn more about the different solutions/applications for source control to expand your knowledge to recognize when it is time to switch solutions but stick with what works for now.
以下是 切换到 git 的 3 个理由来自 Subversion（来自 MarkMcB）：
（阅读链接的文章，了解如何做这三件事的完整解释和直接比较在 git 和 Subversion 中。）
Here are 3 reasons to switch to git from Subversion (from MarkMcB):
(Read the linked article for full explanations and direct comparisons of how to do the three things in both git and Subversion.)
我个人也愿意继续使用 Subversion，
还有更好的吗？
Subversion 是一个很棒的版本控制系统，您对它很满意，所以如果您想进一步了解，我可以推荐您获取一些有关 持续集成，有很多工具可以帮助您进行自动构建，使您的构建进行自我测试，请检查每次提交的完整性，以及更多...
I also personally would stay with Subversion,
Is there anything better?
Subversion is a great version control system, and you're happy with it, so if you are looking further, I can recommend you to get some info about Continuous Integration, there are many tools out there that can help you to make automatic builds, make your builds self-testing, check the integrity of each commit, and much more...
Mercurial 也值得考虑； 分支更加友好，并且无需网络连接即可工作。 在从 SVN 迁移到 Mercurial 之前，我从未认真尝试过将工作划分为分支。
我非常怀念的一件事是 TortoiseSVN； 有一个类似的工具（TortoiseHg）非常好，但它只是不一样。
无论如何，从 SVN 创建 Mercurial 存储库非常简单...尝试一下，看看它是否适合您。
Mercurial is also worth consideration; branching is much friendlier, and it can work without a network connection. I never seriously tried separating work into branches until I moved from SVN to Mercurial.
The one thing I seriously miss is TortoiseSVN; there's a workalike (TortoiseHg) that's pretty good, but it's just not the same..
Anyway, creating a Mercurial repo from an SVN one is trivially easy...give it a try and see whether it suits you or not.
规则编号 1：“永远不要更改正在运行的系统”
此外，由于有许多闪亮的新解决方案（对于您单独工作时没有的问题），您应该考虑切换到新的 VCS 的成本：
将 subversion 导入到 Mercurial/git 并不是一件容易的事，
没有工具（据我所知），它使用转储格式导入 svn 存储库。 因此，如果您不使用转储格式，您将坚持从 svn 中签出所有分支/标签，并手动/通过脚本将它们添加到 git/BZR/Mercurial
所以我不知道您的存储库有多大（我的存储库范围为 20 MB到 24GB），但是检查整个存储库需要很长时间，甚至带有大量标签的小项目也会占用大量硬盘空间。
另一个问题是，在迁移完成之前，您无法继续工作。
Rule no. 1: "Never change a running system"
Also, as there are many shiny new solutions(for problems you do not have, as you work alone) you should consider the cost of switching to a new VCS:
The import of subversion to Mercurial/git is not an easy task
there is no tool (AFAIK), which imports svn repos by using the dumpformat. So if you do not use the dumpformat you will stick to checkout all branches/tags from svn and adding them to git/BZR/Mercurial manually/via script
So I do not know how big your repos are(my repos are ranging from 20 MB to 24GB), but it will take a long time to check out a whole repo and even small projects with lot of tags will eat up a lot of harddisk space.
Additional problem is the time until your migration is done you cannot continue to work.
有一句古老的洋基谚语。
如果它没有坏，就不要修理它。
There's an old Yankee proverb.
If it ain't broke, don't fix it.
我和你一样，为了获得最好的工具而不断调查。
我尝试使用 SVN 进行 SOLO 工作，有人推荐我 Mercurial (hg)。 现在我对此做主题演讲。
比windows下的git更友好。 我现在想“为什么 svn 会使像标签这样的简单任务变得复杂”。 SVN 不知道标签是什么。 对于 SVN 来说，标签是一个副本。
在 Mercurial 中，标签是修订版的别名。 到底有多复杂呢？
性能是另一个问题。 在 Mercurial 中，您的存储库位于您的本地计算机中。 因此，对于日志、差异或历史记录来说，速度非常快。
尽管我对支持 Mercurial 的存储库在线版本的服务器一无所知。
I am just like you in the issue of constant investigating in order to get the best tool.
I tried SVN for SOLO work and someone recommended me Mercurial (hg). Now i do keynotes about it.
It's more friendly than git in windows. I now i think "why do svn complicates with simple task like tags". SVN doesn't know what a tag is. For SVN a tag is a copy.
In mercurial a tag is an alias for a revision. How complicated could it be?
Performance it's an other issue. In Mercurial your repo it's in your local machine. So it's very fast for a log, or diff or history.
Although I do not know anything about servers that support mercurial for a online version of your repo.
即使您实际上没有使用分布式工作流程，也绝对值得研究“分布式”VC。 能够拥有私有分支并控制本地提交是值得学习 git 的努力的。 我主要使用 git-svn （其他团队成员使用常规 SVN 客户端，因此我们有一个正常的、集中的工作流程），并且它运行得非常完美。
It's definitely worth looking into "distributed" VC even if you're not actually using a distributed workflow. Being able to have private branches and control over your local commits is worth the effort of learning git. I've been mainly using git-svn (with other team members using regular SVN clients, so we had a normal, centralized workflow), and it worked pretty flawless.