SVN使用不佳-Mercurial是答案吗？

13

在工作中，我们使用SVN，但仅是名称。我们不分支或合并。我们保留该存储库的两个副本，其中一个充当“标签”分支，在进行部署时会被复制，并保留用于错误修复和立即“必须尽快上线”的功能。我们必须记住将一个副本中所做的更改复制到另一副本（“主干”）中。我们在存储库中的一个文件夹中有十二个项目，而不是将它们分开。简而言之，我们使用SVN的唯一目的就是能够提交。其他所有操作都是手动完成的。

我一直在评估Mercurial；我过去曾经使用过Git（我是团队中唯一使用过DVCS的人），而且我正在迅速接手Mercurial。我正在讨论将Mercurial作为一种“更好的做事方式”介绍给团队的其他成员，因为分支很容易，合并更容易，而且我们可以将内容本地化为我们的核心内容，而只将它们推送到中心准备好后分支。我们将获得SVN的所有好处（而且由于没有人真正了解SVN，我们现在并没有得到太多好处），而且对于新功能，我们不必拥有大量未版本化的文件，因此，如果我们必须回滚我们搞砸了。工作流程似乎更简单-我们只需要记住“ Commit”是本地的，“ Push”就像SVN的提交，

这是一个好方法吗？请记住，团队非常灵活，将与一切能够改善我们的工作质量并使我们的工作变得更轻松的事情一起工作-CIO甚至问我，当我提到我们不充分利用SVN的潜力时，有更好的东西可以使用吗？” 所以他也同意。

version-control svn mercurial

— 韦恩·莫利纳（Wayne Molina）
source

13

HgInit-从颠覆再教育开始，我认为您会发现它很有用。

— yannis 2011年

20

您是否不怕它们最终也会用尽汞呢？

— 奥德

6

我认为DVCS对于您的情况将是一个可怕的想法，因为学习曲线更高，而且您作为组织的组织显然在努力利用SVN的基本功能。只有在您利用SVN中的标签，适当的存储库组织和适当的合并技术并发现仍然缺乏您的需求之后，才应转向DVCS。

— maple_shaft

2

@WayneM选择在DVCS上使用SVN不一定完全是错误的。有些人（包括我本人）在SVN中合并没有任何问题，并且发现DVCS所增加的复杂性胜过了所能想到的好处，尤其是在您的团队规模较小的本地化团队中。在加入一支庞大的开发团队后，我可能不会非常认真地对待DVCS。

— maple_shaft

4

@maple_shaft I will probably not take DVCS very seriously until I end up on a large development team或者直到您结束一个分布式团队。我们是一个小团队（5人），在3个地方工作（有时不希望起床，有时则是5个），从svn切换到hg值得欢迎……

— yannis

15

是。

如果在您的OP中将“ SVN”替换为“ Perforce”，则几乎可以理解我在开始当前工作时遇到的情况，甚至是手动更改复印。两年后，我们开始使用Mercurial，每个人都同意这是一个巨大的变化。

我们具有按支持案例进行分支和合并的功能，这对于质量保证而言非常有用，并且能够在我们认为合适时创建任意数量的一次性分支机构和存储库，然后可以在CI服务器中进行构建和验证，然后进行部署到云测试环境并验证功能。就安心而言，这具有巨大的好处，当我们进行实时部署时，我们几乎100％确信它会工作（没有环境/数据库问题，这显然超出了VCS的范围）。

基本上，我们从转换为水银获得的就是呼吸空间。我们不再需要担心分支机构的成本，也不必担心不可避免地要遵循的可怕的合并会话，一切都变得容易得多。我们还大量使用FogBugz，因此与Kiln（他们托管的软件）的搭配非常有帮助。

关于hginit站点的评论也很明显，它是实际工作的版本控制工作流的概述（假设您针对公司的特定QA工作流进行了调整）。

移动版本控件的唯一可能缺陷是，您将需要一个真正推动变更的驱动力，乐于阅读主题并真正发挥其潜力的工具，而您似乎想要做。

我不同意关于是否使用DCVS的有关团队规模和团队分布的评论。确实，这与CODE分发有关。如果您有多个并行开发周期，或者是旧系统上的支持案例，或者是一堆功能甚至是新系统（根据您的说法，这样做），您将从使用DVCS中受益。

— 埃德·詹姆斯
source

3

-1，如果开发人员已经在Subversion中遇到这样的问题，那么他们极不可能“得到”一个更复杂的系统。正确的答案是，如对该问题的评论所述，是对Subversion（和VCS通常）如何工作的重新教育……

— Izkata

1

@EdWoodcock，我认为您观察到的内容可能确实是由于您的团队从“干净的开始”开始。VCS全面转变为水银，这意味着每个人都必须重新开始，并且不再依赖于他们在SVN中使用的不良习惯。很多时候，克服另一种情况下的“重新开始”的坏习惯（在这种情况下是轻浮的）比较容易。

— Angelo

2

@EdWoodcock：在所有仍在使用的VCS中，Perforce的分支可能最差。SVN中的分支要容易得多。

— 凯文·克莱恩

1

无论使用哪种版本控制系统，我都认为“制定规则”并花费时间与团队一起讨论所有使用情况非常重要。人们并非天生就知道如何进行分支，标记和签入，不同的团队以不同的方式来做这些事情，而VCS系统不会在一个工作流之上执行另一个工作流。如果团队成员的期望和使用情况不在同一页面上，那么版本控制将成为一场噩梦。这些是所有VCS系统常见的问题。

— Angelo

1

@ChrisS该寓言更适用于分支成本较高的标准VCS。另外，它谈论的是分支，提交，然后再次合并，每次在DVCS中克隆<i>您要做的</ i>。另外，我刚刚概述了为什么这种方法真正适用于我们；为什么？坚持方法论是很愚蠢的。

— 艾德·詹姆斯

21

一个不同的工具可能无法解决您的问题，我想说您应该阅读这篇文章，我发现它最有帮助：

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

我认为本文的要点总结如下，但请务必阅读：

最后：不是真的关于工具

在我与不同的源代码控制系统一起工作和集成的所有时间里，我得出一个结论：这不是工具，而是您使用它的方式。这是一个骇人听闻的声明，但在这里似乎尤其如此。当用于正确地管理源代码更改时（如为构建进行标签，按异常分支等），即使是最薄弱的源代码控制系统（* cough * SourceSafe * cough *）也将远远超过Mercurial设置，并带有一些偶然的提交和推。

— 黑冰
source

6

+1，实际上与工具无关。SVN和perforce完全一样。

— Angelo

1

这全是关于人的，而不是工具。我看到还在使用版本控制并行版本系统，运行git或水银..很好地管理项目，以及可怕的项目

— 亚历山大·加尔金

并不是真正意义上的工具，除非您有出色的工具来赞美github，bitbucket之类的源代码控制提供程序

— Chris S

3

我同意这是您使用工具的方式重要的一面，不同的工具也会引导您朝着不同的方向发展。诸如Mercurial之类的工具可以带您走上简单性和灵活性的道路。Git引导您走上复杂但极端灵活性的道路，Subversion使某些事情比其他事情容易，因此使您摆脱了困难和棘手的事情，而Visual Sourcesafe则使您走下了极端僵化和挫败感。* 8'）

— Mark Booth 2012年

10

不会。技术很少能解决此类问题。

Mercurial比Subversion复杂（是的，分支和合并更好，也许更容易，但是Subversion的模型比Mercurial的模型简单得多）。如果您以这种死脑筋的方式使用Subversion，则可能最终会使用Mercurial：

a）足够或更好
b）不足，但比您当前使用的Subversion更好
c）像现在这样不够
d）比现在更糟

c）和d）听起来像是最可能的结果。写下为什么会以a）或b）结尾的原因。

— 亚历克斯
source

5

我无法谈及大型团队的工作方式，但是对于小型团队而言，许多大型SVN问题并不是真正的SVN问题……它们是开发问题。如果您不遵循现代开发标准（最重要的是，进行持续集成），那么版本控制将变成您所描述的确切混乱……在过渡到新系统之前，请确保对您的问题进行真正的根本原因分析...

— 布莱恩·诺布拉赫
source

3

不会。工具不能替代方法论。

如果您不使用Subversion作为SCM，那么您也 不能使用Mercurial（这很可能会发生）

— 懒Bad
source

2

SVN可以做您需要做的事情，并且无需为获得可疑的回报而在中游阶段换马。

无论您做什么，都必须克服信任问题。必须有人能够说服所有人改变他们的工作流程。即使在最佳情况下，即使您拥有逻辑和事实，这也不容易。这是组织中最难做的事情之一。如果您破坏它或使其变得粗糙，您将失去信任，并且很难重新获得这种信任。

我知道人们已经成功尝试了几件事。也许其中一个会为您的团队工作：

引入“教练”为团队提供一系列的研讨会。这很可能必须是外部人员（具有讽刺意味的是，与信任团队中的某人相比，许多团队信任外部人通常更容易）。它必须是一个从内而外了解她的东西的人，并且可以有效地向各个理解水平的人教授这些技能，并制定一个务实的计划，以将新的VCS（*）推广到团队的工作流程中。
启动一个“ skunk-works”项目，以在一个小型副项目上测试驱动并验证新的VCS。选择几个愿意尝试新事物并且不介意进行一系列不成功的实验的“ alpha”开发人员。当臭鼬作品能够证明工作流程中混凝土的无可辩驳的改进时，您便可以尝试将其推广到团队的其他成员，并且您可以有两名传教士来帮助您。

（*）用“新VCS”表示，我不一定是指水银或git，也可以是SVN（正确）。

— 安杰洛
source