仍然使用Subversion的特定原因？[关闭]

22

我想为我的公司选择一个版本控制系统。到目前为止，我知道我有Git，Subversion和Mercurial。

这些天来，我发现Git是最常用的，所以我不禁要问：仍然有任何特定的原因仍然需要使用Subversion，还是应该直接使用Git？

version-control git svn

— 用户名
source

36

他们俩都工作。重要的是它们是否可以满足您的要求，而您尚未告诉我们。

— 马修·弗林

6

请参阅为什么使用SVN？那里有任何隐藏的职业玩家（超过GIT / Mercurial / Bazaar）吗？在堆栈溢出。

— 熟练地

11

您在哪个论点上排除Mercurial？

— mouviciel 2012年

8

-1表示主观（诱饵恕我直言）措辞和“那些天，我看到Git是最常用的”-需要引用。Git在开源世界中极为普遍，但在公司领域则更为罕见。军团真的很喜欢一个单一的，中央的，权威的仓库的想法，而且变化非常缓慢。在企业领域，您甚至比SVN更有可能看到优质的CVS，不用管DVCS。

— Keith

4

@RobinWinslow-SVN与Git不同。更适合某些情况而较不适合其他情况。就我个人而言，我总体上更喜欢DVCS，而您显然更喜欢Git，但这两者都是主观意见。它们并非没有价值，但它们不属于这样的网站。

— Keith 2012年

46

SVN完全没有死。它的使用仍然非常广泛，并且很快就不会在任何地方使用。SVN比分布式版本控制更易于使用，尤其是当您实际上没有运行需要分布式版本控制的分布式项目时。

如果您只有一个中央存储库（如果到目前为止它们还足够小而没有源代码控制，那么公司将需要这些存储库），使用SVN与其进行交互要简单得多。例如，使用SVN，您可以通过一次操作从存储库中提取更改，或将存储库中的本地更改提交给SVN，而HG和Git需要两个或三个步骤来完成等效的工作。

在最近的修订中，SVN解决了许多使人们偏爱HG和Git的性能问题。现在它的速度比几年前要快得多，并且在这一点上，除非您确实需要分布式版本控制的高级功能，否则没有充分的理由为您的项目研究HG或Git。

— 梅森·惠勒
source

16

我并不完全同意您的估计，但我想补充一点支持SVN的观点：业内许多人对SVN感到满意，但对Git的了解不足以使其舒适地工作。如果您的整个团队都习惯了SVN，那么切换到Git可能会付出很大的代价。（当然也可以相反）。

— 约阿希姆·绍尔

8

如果可以的话，我会投票数十次。许多人都追随时尚，但真的不认为为什么他们需要分布式源代码控制。

— 欣快感2012年

21

@Euphoric：我很清楚为什么我总是希望在每个项目上进行分布式源代码控制。它具有使分支和合并变得简单，明显和可靠的重要副作用。在带有分支的特殊情况下，Subversion仍然陷入困境，因为它选择的基本模型只会使其变得更加复杂。

— Jan Hudec

18

分布式版本控制不是“时尚”。它是源代码控制的演变，就像并发版本控制是文件锁定范例的演变一样。

— JesperE 2012年

6

@MichaelBorgwardt，实际上我做了很多次。它比使用颠覆要容易得多，因为一切都是本地的，这大有帮助，无需解释“客户端”和“服务器”的交互作用。git或hg中的工作流更加自然和直观（如果您远离诸如历史记录编辑之类的棘手位）。

— SK-logic

19

尚未提及客户端工具。您当然可以使用命令行脚本来完成所有操作，但是具有GUI集成可以真正提高生产力。

我们主要与Visual Studio合作；使用SVN集成到IDE中肯定比现在使用Git更好。将来这可能会改变，但是我一定会在版本控制功能方面同样考虑到您的决定。

就像其他所有内容一样，版本控制系统本身并不是目标，而只是使您步入正轨的工具。根据您的情况选择一个可以使您最快到达那里的人。

— njr101
source

这是好点。我认为人们偏向Git而不是SVN的原因之一是Git具有更好的CLI工具。但这可以通过良好的第三方SVN GUI（例如Windows上的TortoiseSVN）来抵消。

— 欣快的2012年

2

这是我们选择水银（和TortoiseHg）胜过Git的原因之一。分布式版本控制以及不错的工具和IDE集成的优点。

— HappyCat 2012年

15

我是Git迷。最近，我不得不承认，Git的缺点之一是它标识带有哈希的版本与svn的发行版号相反。发布号可以更容易地通过电话或类似方式传递。

那是我能想象的唯一的专业人士。如果您真的想依赖该功能，则可以在分布式和/或集中式VCS Bazaar中使用它。在Git中，有可以达到目的的标签。

无论如何，如果没有快速的分支切换和存储，我简直无法想象。仅这两个功能就击败了SVN，据我所知，到目前为止，同一任务需要创建并检出整棵树到单独的目录中以实现相同的目标。

这些所谓的“分布式版本控制的高级功能”会随时间而来，您不必一开始就学习它们。不要害怕他们。他们在这里是为了帮助您，而不是妨碍您。并且为DVCS设置中央存储库没有问题。

— 拉吉什
source

1

这实际上是没有实际意义的，git只需要散列的足够大的部分就可以消除歧义，通常〜6个字符就足够了，而不是整个散列。

— TC1 2012年

2

实际上，您永远不会传递git哈希。您可以使用哈希的任何唯一前缀，通常为6-7个字符。

— JesperE 2012年

1

@JesperE：是的，但是SVN的发布数量会随着时间的推移而顺序增加，而Git的哈希（即使您缩写它们）也可能是随机的。

— 基思·汤普森

2

使用SVN，您可以轻松地检出存储库的各个部分，直至文件夹级别；而使用git，则可以获取整个存储库，包括所有历史记录。

根据情况，这对于SVN可能具有一些优势

（这也有一些很大的缺点，例如在文件夹树上一直隐藏着“ .svn”垃圾）。

— 理查德·尼科尔斯
source

3

注意：从v1.7开始，没有.svn垃圾-现在所有垃圾都存储在一个位置。

— gbjbaanb

这是不正确的-git允许您仅签出文件，没有历史记录，并且如果需要，也可以只签出回购的一部分-单个文件。它比svn复杂一点，但是容量就可以了。

— Benubird

2

“如果您的任务可以在六个小时内完成，那么即使编写工具需要六个小时，最好编写一个可以在20分钟内完成的工具？”

分布式版本控制是要解决的另一种难题。每个开发人员都需要大量学习。如果您有足够的缓冲空间来适应每个开发人员的学习过程，则应该使用良好的分布式版本控制系统。一旦学习阶段结束，分布式版本控制将比集中版本控制好得多。

分布式版本控制似乎是一种偶然。它在这里停留了很长的时间，最好早一点适应。我还记得当SVN是新的并且人们习惯了CVS时的相同讨论，很多人提出不使用SVN的争论，但最终SVN成为最受欢迎的版本控制系统。

如果公司在现有版本控制系统中建立了很好的源代码，那么迁移到新系统是一项艰巨的任务，但是如果公司规模很小或刚起步，则迁移到新版本控制非常容易。但是，如果您坚持使用较旧的版本控件（在新设置中），则将来会遇到瓶颈，无论如何最终您都必须计划版本控件的迁移。

我已经看到了很多关于SVN的专业评论，但是所有这些评论的性质都是“ SVN不错”，而不是“ SVN更好”。因此，我强烈建议您为项目选择一个分布式版本控制（例如Git）。

与SVN相比，GIT的编辑优势

~~不需要专用服务器~~ 实际上，两者都可以与服务器一起使用。
即使没有网络连接也可以继续开发。
分支机构管理容易得多。
CI工具（例如Bamboo）提供了更好的支持

有人提到工具（用于Visual Studio）是坚持使用SVN的原因。http://gitscc.codeplex.com/为Visual Studio提供了GIT支持。

— Apeirogon Prime
source

6

SVN 确实比Git或Hg 处理二进制文件更好。

— 假名称

2

“将来，您将遇到瓶颈，最终必须计划版本控制迁移……”对不起，我不能同意这是今天采取行动的一个很好的理由。我已经在许多项目中工作过，这种方法导致事情变得比他们需要的复杂得多，并且该项目很早就被取消，之后才可以利用这些未来的利益。有时足够好，足够好。坚持使用YAGNI，今天就干什么。以后有足够的时间担心迁移了。至少您还会有一个项目。

— njr101

2

Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.我完全不同意这一点。在某些情况下，它可能会带来一些好处，但在许多组织中，诸如svn中易于理解的版本号之类的东西却是巨大的好处。

— TZHX 2012年

1

@apeirogon-一切都取决于您要放入存储库中的内容。我使用的主要存储库之一的HEAD本身就是11.1 GB！如果我在Git / bzr / hg仓库中使用它，则可能会占用100+ GB。

— 假名称

1

当然，这是因为此特定回购文件中充满了PCB文件和3D模型，这些文件和文件都是二进制格式，而且空间效率不高。此处的建议（Electronics.SE，例如用于存储PCB ddesign文件的人员等）与针对存储源代码的人员的建议完全不同。

— 假名称

1

那些日子有什么特定的原因使用Subversion

除了IDE中的工具支持（我不使用）之外，不是，不是。当然，SVN可能更熟悉，但这是唯一的原因，而且我发现Hg和Git都非常容易（而且非常快）学习。

是的，当您了解分支只是映射希尔伯特空间子流形的同胚内胚函数时，所有这些复杂的指南都描述了Git的琐碎之处。^1个

我不明白但是你知道吗？没关系使用Git，您不需要了解任何这些知识。

在大多数情况下，Git和Hg易于使用，并且比SVN具有确定的优势。房间里的大象当然是在分支：分支只在Git和Hg中起作用。相比之下，在SVN中，它们充其量是痛苦的，而最坏的是破裂（合并多个头）。

当然，您仍然可以使用SVN。您仍然可以使用Windows XP。但是，大多数尝试过这两种方法的用户都同意，其中一种替代方法要优越得多。

¹是的，我知道这是个玩笑。我认为。

— 康拉德·鲁道夫
source

一个Git教程，它具有同胚的endofunctors映射Hilbert空间的子流形？我需要阅读！但是，这是否不适用于Darcs，它是由Haskell（我认为endofunctor指的）写的，并且受量子力学的启发（因此称为Hilbert space）？我真的看不到Git和HG与这些事情有什么关系。

— 大约

@leftaroundabout这是个玩笑。该描述甚至不准确（据我所知）。这是许多教程的重复之处，这些教程以“一旦意识到... git分支就很容易”开始，然后是一个复杂的特定于领域的隐喻。

— 康拉德·鲁道夫2012年

1

您是否曾经考虑过所有那些过于复杂的教程是有原因的？那到底是什么呢？我从不了解DVCS人群对分支的痴迷，然后对每件事都重新整合了分支。在我看来，这始终是寻找问题的解决方案。在SVN中重新集成分支非常困难，因为首先这是一件很愚蠢的事情，而且在概念上是错误的，而且我真的没有找到任何归结为“我们的产品使做错事情变得容易得多”的论点。非常有说服力。

— 梅森·惠勒2012年

1

至于并行处理多个更改，我会承认这有些痛苦，但是正确的解决方案是搁置，这是在下一个SVN版本中计划的。而且在大多数情况下，如果您同时进行多个更改（尤其是如果您始终如一地进行操作！），则表明存在更广泛的问题，应在组织级别解决此问题，而不是通过新功能启用工具。（请参见上文，“我们的产品可以使做错事情变得容易得多，”和乔尔关于人类任务切换的经典文章。）

— 梅森•惠勒

3

@KonradRudolph在最新版本的SVN中，将分支合并回主干工作正常。几年来一直稳步好转，直到现在变得非常好。

— 亚当·布鲁斯