26

我搜索了git / mercurial / bazzr系统，使其优于集中式系统（subversion，perforce），但没有找到任何商业原因。

如果您试图将DVCS出售给非技术人员，您会为DVCS 增加利润提供哪些论点。

我将很快向我的经理介绍git，这将需要一些时间来转换出Subversion存储库，并花费一些费用来购买smartgit许可证。

编辑我试图使这个问题成为关于集中式与分散式的一般性讨论，但是不可避免地它变成了git vs subversion。当然，有比颠覆更好的集中式系统。

— o
source

1

我们正处于类似的立场，正在考虑提出这一案子，不得不说，我不相信目前有这样的案子。

— 乔恩·霍普金斯

能git-svn满足您的需求吗？

— JBR威尔金森2011年

@JBRWilkinson我刚刚使用git-svn将一堆存储库迁移到git。该公司在与svn集成的工具上投资不多，因此问题不大。

— Keyo

引用编辑内容-您仍然没有解释SVN如何以及为什么使您失败，以至于您感觉需要替换。我的回答（例如）是不是约混帐VS SVN约找到一个商业案例，改变现状的。

— Murph

23

嗯，作为一名经理，我对此有两个立即的“下意识的反应”：

如果您还没有充分的理由，为什么除了时髦之外又要宣传git？
同样，Subversion如何失败以致您需要更换？

实际上，我不是负面的-我认为可能要提出一个案例（取决于具体情况），但是如果案例仅仅是git比颠覆“更好”，那么您实际上就没有了。

您还需要能够列举缺点-已经确定了迁移和重新安装工具的开销-还有什么问题？例如，您的漂亮的中央备份存储库会发生什么？如何与持续集成构建服务器集成（如果您没有集成服务器，请忘记git并首先进行排序）。安全和跟踪-SVN具有正确的登录名和权限。

在我看来，好处在于灵活性，更好的合并，在不破坏构建的情况下进行本地提交的能力等。缺点是缺乏控制和相同的灵活性。

可能您要做的只是作为“更好的” Subversion客户端在计算机上本地运行git（我正在使用mercurial进行此操作）。

嗯，也许这整个答案真的是评论吗？您需要在此处（问题中）针对git over Subversion（在您的环境中）进行论证，以便了解我们是否可以帮助您确定业务案例。

FWIW，我知道人们可以轻松地将存储库的特定实例指定为中继/参考源，而且这就是将其连接到构建服务器的方式-区别在于DVCS的管理决策更多体系结构中固有的东西。

— 墨菲
source

1

解决权限/灵活性问题：您仍然还需要一个“源”存储库，您实际上可以像往常一样设置权限。持续集成针对源存储库运行，开发人员可以克隆源存储库等。但是，由于每个人都有一个克隆，而不仅仅是检出它，因此备份的重要性不那么重要。

— Matthieu M.

1

关于完全克隆作为备份的观点是正确的。我会自由地承认，在某些方面我还不太了解，因为我的“工作”资料是svn，而我的工作是个人的，但仍然有些局限。

— Murph

14

我想说，快速而轻松的分支与合并将使开发人员可以提高他们的代码的生产力，因为每个新功能都可以进行分支，然后再合并。使开发过程更加顺利。而且，分布式特性将允许每个开发人员拥有完整的代码副本，因此不必担心集中式服务器故障会导致您删除所有代码。可能还有更多原因，但这两个是我使用Git的首要原因。

— mbreedlove
source

2

在业务环境中，“集中式服务器”将具有冗余，备份和管理员，以使其（以及所有其他服务器）保持活动状态。

— JBR威尔金森2011年

2

在大型业务环境中，您将拥有服务器冗余。在小型企业中，这种服务器冗余不是很确定。

— Michael Shaw

2

集中式服务器故障不会删除您的所有代码。即使您没有备份，最糟糕的情况是记下修订历史记录。但是，只要所有开发人员都将代码签出，它们也以当前形式存在于他们的系统中。

— 梅森惠勒

1

@mason：但这是一个假设：“只要所有开发人员……”。因为在规模甚至较小的项目的小型公司中，项目可能会生活并且被愉快地使用，而无需任何人对其进行编码一年或一年。两个

— Inca

而且，我不会低估提交历史记录的价值。在庞大的系统中，查看谁和为什么对代码进行操作确实非常有价值。

— 陶Szelei

8

我认为即使开发人员独自工作，您也可以通过版本控制提高生产率（从而提高利润）。

一个好的DVCS即使在团队中一起工作时也能意识到同样的生产力提高-每个开发人员都可以获得使用版本控制的所有好处-他们可以进行频繁的提交，回滚，玩弄其他事情-无需担心冲突与其他开发人员所做的事情，直到他们准备好推出自己的更改为止。

— 阿农
source

这就是我要发布的内容。您当然应该看到开发人员可以尽早且经常将其提交到自己的存储库，从而在不给任何同事造成麻烦的情况下提高生产率。

— Carson63000

5

然后，当您最终推动更改时，您将陷入集成地狱。这是一件坏事，不是一件好事。

— 亨利

在进行具有大量提交的本地开发工作时，您可以继续从中央存储库中提取更改，并使本地更改与其他人正在进行的正在进行的开发保持一致。因此，当需要将更改推送到中央存储库时，您应该已经在其中进行了大多数更改，并且集成将很容易。

— DaveJohnston 2011年

1

除非您的一位同事做了完全相同的事情，而且你们俩都已经很长时间没有融合了，总会有权衡。我确实看到过这样的情况，即某些东西已经被整合到了主线上，而不应该被整合（错误的解决方案，对解决方案的盲目的尝试等等），在功能完整的情况下进行整合也带来了好处。

— 若佩

2

您不能使用（a）SVN分支或（b）多个工作副本来做所有这些事情吗？

— JBR威尔金森2011年

4

每个错误的分支
减少差异延迟。
当您进行同行审阅时，能够非常快速地任意浏览分支的历史记录。
当您无权访问集中式服务器时，您仍然可以访问整个历史记录：您不在办公室，只是断电了，但笔记本电脑的电池仍在工作，...

这些东西使您可以更有效地工作，无论是单独工作还是团队协作。工作效率更高=更快的开发时间=更快的上市时间=利润。

— 弗兰克·希勒（Frank Shearar）
source

3

原谅我链接到我自己的博客，但是我已经写了有关此主题的文章：

如果您认为它们不相关，请随时投票。

简而言之，DVCS使分支模型变得容易，这可以防止大量开发人员互相踩脚趾，从而提高了生产率和日常构建质量。版本控制的混乱协作部分可以在本地存储库中完成，从而使中央存储库更干净，质量更高。此外，关于何时分支的决定可能会对效率产生很大影响，例如，当一个部门准备好在2.0仍由其他部门清理时准备开始在2.0上工作。DVCS允许那些决策在本地而不是由委员会做出。

— 卡尔·比勒费尔特
source

您的博客条目写得很好。我还没有全部阅读。我想知道当Git和Hg似乎更受欢迎时，为什么选择Bzr。人们似乎讨厌Bzr的速度慢。我也是Git的粉丝，因为它是哈希表而不是修订号，对我来说这似乎很安全。合并分支时，bzr版本号是否会全部打乱？

— Keyo

2

@Keyo，我选择bzr是因为我必须自己教DVCS，而bzr是最适合新手的。从那以后，为了速度，功能和稳定性，我已切换到git。Bazaar还会对其修订进行哈希处理，并具有全局唯一标识符，它们并不是向用户公开的默认标识符。他们的修订版本号是不是使用真的没有什么不同HEAD~1，HEAD~2等在饭桶。您很少需要实际的哈希，但这是您在git中学习的第一件事，并且始终在您的面前。除非确实需要，否则将其隐藏在用户面前是bzr更加友好的新手原因之一。

— Karl Bielefeldt

感谢您的澄清。对我来说，Git从颠覆中并不是一件容易的事。许多命令具有相同的词，但功能却不同。

— Keyo

2

我对DVCS的论点是：

分支不会中断，从而减少了开发功能并保持现有产品修补的摩擦。摩擦会花费时间。
转向现代系统会更好地吸引尖端开发人员，这将导致更好的产品文化，使企业能够销售更多产品。
非网络提交速度更快，从而使开发人员可以经常提交，从而可以进行细粒度的错误检测和分析。

本质上，这是关于减少摩擦。有一个术语：Muda。摩擦越大，做事情就越痛苦。痛苦越多，完成的事情越少，利润就越少。

— 保罗·内森（Paul Nathan）
source

2

如果我很杰出，我深表歉意，但请允许我以不确定的方式提出业务案例：

SVN使开发人员的生活痛苦不堪。这使软件业务陷入困境。

...以许多人直到开始使用DVCS才意识到的方式。 这是可以做出的最重要的业务案例。为什么？好吧，与寻找和保留优秀开发人员的成本相比，切换到DVCS的成本几乎不存在。

考虑以下：

SVN（以及大多数其他CVCS）中除最简单的操作外的所有操作都需要网络访问。在大多数DVCS中，仅当您执行push或pull操作时才发生网络访问。这意味着非平凡的命令很慢。当命令永久执行时，您会怎么做？我在等待的时候亲自去浏览developer.se或黑客新闻。简而言之，DVCS使程序员可以专注于做自己喜欢做的事情：编写公司的软件。
SVN对分支的支持与监狱对在淋浴中滴肥皂的支持几乎相同：您可以这样做，但是当您这样做时，就会上瘾。因此，SVN迫使您的开发人员不断地相互竞争以进行更改。
SVN关闭时，它也关闭。如果开发人员根本无法完成工作，将变得非常困难。因此，SVN迫使您的开发人员依赖于您的基础架构100％无缺陷。
这些天来，git正在迅速获得关注，而SVN正在迅速失去它。 如果在SVN上使用DVCSes没有任何好处，那么为什么编程社区会尽快改变呢？

这一切意味着什么？我还没有见过对DVCS进行过诚实尝试的开发人员，之后他会更喜欢SVN。如果我能再做出一个令人讨厌的，大胆的声明，那么SVN就是开发人员强迫自己使用的“必不可少的罪恶”。Git是使开发人员更加高效和快乐的工具。

（我应该指出，粗体语句是您应该关注的特定语句。其余语句仅提供上下文。）

— 杰森·贝克（Jason Baker）
source

5

-1-您很出众，尽管您写的内容有些真实，但它的含义是如此消极，以至于趋向于FUD而不是理性的分析。SVN慢吗？仅当存储库很大且网络很冰爽时。SVN停止运行了吗？erm，记不起它曾经关闭过，并且没有，因为我的计算机不依赖于存储库的存在来编辑/编译/运行源代码。SVN分支和合并不畅吗？哇，人们记忆犹新……为什么DVCS赢得人们的关注？功能混搭-进行了改进-坦率地说，是时尚。

— Murph

1

@Murph-不管喜欢与否，人们讨厌改变到变得笨拙的地步。要说服他们进行更改，您需要说服他们现状已破灭。它被打破。只有在没有理由害怕，不确定和怀疑的情况下，FUD才是坏的。至于分享心得，我同意你的看法。但这不是重点。这是决策者是否同意这一点。我曾经见过的每个经理都对这种说法深信不疑（即使他们讨厌 git）。

— 詹森·贝克

2

我不一定非要与您不同意，杰森只是暗示您的观点做得不好。具体来说，我认为您正在为效果而骄傲，如果您被发现这样做，即使您是对的，也往往会为自己的论点丢分。（当然，除了您错了的地方之外……（-：）

— Murph

2

您的所有观点都是观点而非事实。我会逐一列举，但注释中没有足够的空间。没有出色的表现，您又如何回答？

— 亨利

1

@Henry-Programmers.se用于主观问题和解答。主观==意见问题。

— 詹森·贝克

1

我唯一能想到的是git在没有网络连接的情况下可以正常工作。甚至在相当长的一段时间内，其他所有东西通常也很难卖给使用沉没或强迫的技术用户。

— 脑滞后
source

2

可以，但是Subversion在没有网络连接的情况下也可以正常工作。（显然没有提交，但是常见的事情，例如获取有关工作副本的信息或与基本修订版进行比较都可以。）

— j_random_hacker 2011年

@j_random_hacker：VCS的目的是跟踪代码更改。提交跟踪代码更改。如果您不能离线提交，我会认为您的VCS在离线时不起作用。

— 2011年

1

有麻烦时的区别表示

在移植了已有十年历史的存储库之后，我们在6个月前切换到了git。

经过一些实验，到目前为止，我发现了以下内容：

分支和合并几乎没有痛苦。这样就可以更轻松地进行单独的功能和错误修复，而无需彼此踩脚。这也使得在其他地方应用给定的错误修正非常容易。
通过设计获得更强大的功能-您不必100％依赖可用的中央服务器，如果不是，则可以使用临时升级任何克隆作为热替换。这消除了关键的故障点-如果SVN服务器由于任何原因而关闭，则没有人可以执行SVN工作。如果中央git信息库由于某种原因而关闭，您仍然可以在本地工作和推/拉，以确保复制提交。您甚至可以为此目的而拥有多个异地存储库。
库交互被简化。对于CVS，您基本上需要随时随地访问某些信息。对于git来说，整个存储库都在本地可用，从而使许多事情变得更快。

因此，在日常工作中不会带来太多好处，但是当您遇到某些无法正常工作的情况时，好处就非常明显！

因此，我建议针对您的业务案例，看看灾难来袭时您将如何做...

这与备份的观点相同：仅在灾难发生时才需要它们。问题是当它执行时您将做什么，然后您会接受发生的事情。

0

分支和合并的难易程度是最具体的原因，但是要说服某人，您必须给他们一个具体的例子，说明如何进行改进。

假设您有一些程序员致力于提高应用程序的性能，而他们正处于试验阶段，不知道他们编写的代码是否会成为master / trunk分支的一部分。但是，他们需要经常彼此共享代码，并尝试可能死胡同的想法。您如何管理Subversion中如此频繁的分支和合并？简短的答案是您不会。使用dvc真的很容易，程序员可以在分支中快速尝试新想法并与他人共享，然后再决定该想法是否会持续存在。

— 杰森
source

-1

放弃SubVersion的业务案例是分支支持是产品稳定和维护的障碍。如果您需要发布产品然后继续开发，则需要一个分支。如果使用Subversion，开发人员将无法正确使用分支，因此您将无法继续进行开发，并确保错误修复实际上也可以同时在主干和分支上进行。

— 邵逸夫
source

分散版本控制系统的业务案例

SVN使开发人员的生活痛苦不堪。这使软件业务陷入困境。