GIT vs. Perforce- 两个 VCS 将进入...一个将离开

GIT vs. Perforce- Two VCS will enter... one will leave

提问by Justin Bozonier

So I'm in the process of getting GIT sold at work. First thing I need is to convince everyone that GIT is better at what they're already used to doing. We currently use Perforce. Anybody else go through a similar sale? Any good links/advice?

所以我正在让 GIT 在工作中被出售。我需要做的第一件事是让每个人相信 GIT 更擅长他们已经习惯做的事情。我们目前使用 Perforce。有没有人经历过类似的销售？任何好的链接/建议？

One of the big wins is that we can work with it disconnected from the network. Another win IMO is the way adds/checkouts are handled. More points are welcome! Also we have about 10-20 devs total.

最大的优势之一是我们可以在与网络断开连接的情况下使用它。IMO 的另一个胜利是处理添加/结帐的方式。欢迎多加分！此外，我们总共有大约 10-20 名开发人员。

采纳答案by Aristotle Pagaltzis

The Perl 5 interpreter source code is currently going through the throes of converting from Perforce to git. Maybe Sam Vilain's git-p4rawimporter is of interest.

Perl 5 解释器源代码目前正在经历从 Perforce 到 git 转换的阵痛。也许 Sam Vilain 的git-p4raw进口商感兴趣。

In any case, one of the major wins you're going to have over every centralised VCS and most distributed ones also is raw, blistering speed. You can't imagine how liberating it is to have the entire project history at hand, mere fractions of fractions of a second away, until you have experienced it. Even generating a commit log of the whole project history that includes a full diff for each commit can be measured in fractions of a second. Git is so fast your hat will fly off. VCSs that have to roundtrip over the network simply have no chance of competing, not even over a Gigabit Ethernet link.

无论如何，您将在每个集中式 VCS 和大多数分布式 VCS 上取得的主要胜利之一也是原始的、极快的速度。在您体验之前，您无法想象拥有整个项目历史是多么的自由，只有几分之一秒的时间。即使生成整个项目历史的提交日志，其中包括每个提交的完整差异，也可以在几分之一秒内进行测量。Git 太快了，你的帽子会飞起来。必须在网络上往返的 VCS 根本没有机会竞争，甚至在千兆以太网链路上也不行。

Also, git makes it very easy to be carefully selective when making commits, thereby allowing changes in your working copy (or even within a single file) to be spread out over multiple commits – and across different branches if you need that. This allows you to make fewer mental notes while working – you don't need to plan out your work so carefully, deciding up front what set of changes you'll commit and making sure to postpone anything else. You can just make any changes you want as they occur to you, and still untangle them – nearly always quite easily – when it's time to commit. The stashcan be a very big help here.

此外，git 使得在提交时仔细选择变得非常容易，从而允许将您的工作副本（甚至单个文件中）中的更改分散到多个提交中 - 如果需要，可以跨不同的分支。这可以让您在工作时做更少的记事——您不需要如此仔细地计划您的工作，预先决定您将提交哪些更改并确保推迟其他任何事情。您可以随心所欲地进行任何更改，并且仍然可以在需要提交时解开它们——几乎总是很容易。藏匿在这里可以是一个非常大的帮助。

I have found that together, these facts cause me to naturally make many more and much more focused commits than before I used git. This in turn not only makes your history generally more useful, but is particularly beneficial for value-add tools such as git bisect.

我发现，与使用 git 之前相比，这些事实使我自然而然地做出了越来越多、更有针对性的提交。这反过来不仅使您的历史记录通常更有用，而且对诸如git bisect.

I'm sure there are more things I can't think of right now. One problem with the proposition of selling your team on git is that many benefits are interrelated and play off each other, as I hinted at above, such that it is hard to simply look at a list of features and benefits of git and infer how they are going to change your workflow, and which changes are going to be bonafide improvements. You need to take this into account, and you also need to explicitly point it out.

我敢肯定还有更多我现在想不到的事情。在 git 上推销你的团队的提议的一个问题是，许多好处是相互关联的，而且是相互影响的，正如我在上面暗示的那样，以至于很难简单地查看 git 的特性和好处列表并推断它们是如何产生的将改变您的工作流程，哪些变化将是真正的改进。您需要考虑到这一点，并且您还需要明确指出这一点。

回答by Carl

I use Perforce at work. I also use Git because I would still like some form of version control when I'm working on code and can't connect to the server. No, reconcile offline work just is not the same. Here is where I've found git to be a great benefit:

我在工作中使用 Perforce。我也使用 Git，因为当我在处理代码并且无法连接到服务器时，我仍然想要某种形式的版本控制。不，调和离线工作就是不一样。这是我发现 git 有很大好处的地方：

1. Branching speed - git takes a few seconds at most.
2. Conflicts - P4Merge's auto resolve destroyed a week's worth of work once. Ever since then I would rather resolve by hand when merging. When Git prompts me about a conflict, it is actually a conflict. The rest of the time, git resolves stuff correctly and I save heaps of time.
3. Keeping track of merges - If you have one branch that is continuously receiving merges from two other branches, you know what a headache this can be with perforce. With git, the headache is minimized because the result of a merge in git is actually a new commit which knows who its ancestors are.
4. Permissions - I have lost track of the number of times I've tried to work on a file but couldn't because it was not checked out in Perforce. If you worked with XCode (or any editor that does not have a solid Perforce SCM plugin) offline, you know how irritating this can get. I don't have to worry about that with Git. I make my changes. Git does not stop me and tracks them in the background.
5. Keeping the main tree tidy - With git, I can sort my commits and tidy the code up so that the history looks nice and tidy. None of that "checking in this file because it was supposed to be part of the previous checkin" rubbish. I squash commits like that, because they help nobody.
6. Stashing - Your perforce server needs to be version 2010.1 or newer to use the p4 shelve command.
7. Creating patches - Easy to do in git. Don't know if it is possible in Perforce without using the command line.
8. Mailing patches from the GUI - again, git wins here.
9. Disk space - With perforce, every branch is a copy. That means if your source tree is huge, your disk space gets eaten up fast. This is not even counting the additional space once you start building. Why even have a link between branches and disk space? With git, you can have 100 branches and only one branch at a time ever exists. If you specifically want to work on two versions simultaneously you can clone, do your work and then get rid of one clone if you want, without losing anything.
10. If you're on XCode4, perforce support has been dropped and git support is now built in. If you do cross platform work like I do, this matters a lot. With Visual Studio, you can use git extensions. With perforce, it's equally yuck on both OSes. Well, maybe a little more on mac now with XCode4 on the scene.
11. Finding the faulty checkin (or, git bisect rules) - Ever tried to do a binary search with perforce to figure out where a bug was introduced? Quite a hassle, yes? Even more of a hassle when there have been integrates from other branches in the middle. Why? Because there is no automation for such tasks. You need to write your own tool to talk to perforce and you usually don't have the time. With git, you give it the starting points (the "good" point and the "bad" point) and it automates the search for you. Even better, if you have a script that can automate the build and test process, you can hook git up to the script and the whole process of finding the checkin is automated. That is how it should be.
12. Tracking changes across refactors - Try splitting BigClass into SmallClass1 and SmallClass2. To Perforce, BigClass has now ceased to exist and two new classes (SmallClass1 and SmallClass2 have joined the source tree). To Perforce, there is no relation between BigClass and SmallClass1 and SmallClass2. Git, on the other hand, is smart enough to know that x% of BigClass is now in SmallClass1 and y% of BigClass is in SmallClass2 and that BigClass has ceased to exist. Now, from the point of view of someone who is reviewing changes across multiple branches, you tell me which approach you'd find more useful - Git's or Perforce's. Personally, I prefer Git's approach because it more accurately reflects the actual change in the code. Git is able to do this because it tracks content within the file and not the file itself.
13. Centralized or decentralized: Git is a DVCSsystem while perforce is centralized. A centralized VCS cannot be decentralized later, but a DVCS (especially git) can be centralized. There are several products that add very fine grained access control to git, if that is something the business needs. Personally, I would go with a system that gives me greater flexibility in the long term.
14. Branch mappings: If you want to do branching right in Perforce, you need to create a branch mapping. There are reasons for this, but they are tied to how Perforce conceptualizes a branch. As a developer, or a team, this simply means one more step in the work flow, which I do not consider efficient at all.
15. Sharing work between teams: With Perforce, you cannot break up a submission. Team A is working on feature A. Team B on feature B. Team C works on bug fixes. Now, Teams A & B have to fix a bunch of bugs in order to implement their features. The only thing is, they weren't so disciplined when committing their changes (probably because they're rushing to a deadline) and so their "bug fixes" are parts of larger submissions that also contain new stuff as far as version control on their branches are concerned. However, Team C is now doing a point release and would like to get the bug fixes from the other teams. If they were using Git, Team C could cherry pick the other teams' relevant changes, split them up and only take what they needed without worrying about introducing any partially implemented features. With Perforce, Team C can get the affected files, but would have to separate the relevant changes using a much more manual process.
16. Changing platform - If, for whatever reason in the future, you decide to change your platform of choice, with Perforce, you're at the mercy of Perforce.com and the availability of the tools for the platform of your choosing.
17. Changing to future amazing source control engine X - If you decide to change what you use for source control, extracting your source control history from Perforce and moving it to new system X is going to be a nightmare, because it is closed source and the best you can do is guess - just Google for Perforce to Git migration to get a sense of what I'm talking about. At least with Git, its open source, so it eliminates a lot of the guesswork involved.

1. 分支速度 - git 最多需要几秒钟。
2. 冲突 - P4Merge 的自动解决方案破坏了一周的工作量。从那以后，我宁愿在合并时手动解决。当 Git 提示我冲突时，它实际上是一个冲突。其余时间，git 正确解析内容，我节省了大量时间。
3. 跟踪合并 - 如果您有一个分支不断接收来自其他两个分支的合并，您就会知道这对 perforce 来说是多么令人头疼的问题。使用 git，头痛被最小化，因为在 git 中合并的结果实际上是一个新的提交，它知道它的祖先是谁。
4. 权限 - 我已经忘记了我尝试处理一个文件的次数，但因为它没有在 Perforce 中检出而无法完成。如果您离线使用 XCode（或任何没有可靠 Perforce SCM 插件的编辑器），您就会知道这会多么令人恼火。我不必担心 Git。我做出我的改变。Git 不会阻止我并在后台跟踪它们。
5. 保持主树整洁 - 使用 git，我可以对提交进行排序并整理代码，以便历史记录看起来整洁。没有任何“签入此文件，因为它应该是之前签入的一部分”垃圾。我像这样压制提交，因为它们对任何人都没有帮助。
6. 存储 - 您的 perforce 服务器需要是 2010.1 或更高版本才能使用 p4 shelve 命令。
7. 创建补丁 - 在 git 中很容易做到。不知道在 Perforce 中是否可以不使用命令行。
8. 从 GUI 邮寄补丁 - 再次，git 在这里获胜。
9. 磁盘空间 - 使用 perforce，每个分支都是一个副本。这意味着如果你的源代码树很大，你的磁盘空间会很快被吃光。这甚至不包括开始建造后的额外空间。为什么甚至在分支和磁盘空间之间有链接？使用 git，您可以拥有 100 个分支，并且一次只存在一个分支。如果您特别想同时处理两个版本，您可以克隆，完成您的工作，然后根据需要摆脱一个克隆，而不会丢失任何东西。
10. 如果您使用的是 XCode4，则 perforce 支持已被删除，现在内置了 git 支持。如果您像我一样进行跨平台工作，这很重要。借助 Visual Studio，您可以使用 git 扩展。使用 perforce，它在两个操作系统上都同样令人讨厌。好吧，现在可能会在 mac 上多一点使用 XCode4。
11. 查找错误的签入（或 git bisect 规则）- 是否曾尝试使用 perforce 进行二分搜索以找出错误的引入位置？很麻烦吧？如果中间有来自其他分支的集成，那就更麻烦了。为什么？因为这些任务没有自动化。您需要编写自己的工具来与 perforce 对话，而您通常没有时间。使用 git，你给它一个起点（“好”点和“坏”点），它会自动为你搜索。更好的是，如果你有一个可以自动化构建和测试过程的脚本，你可以将 git 挂接到脚本上，查找签入的整个过程都是自动化的。应该是这样。
12. 跨重构跟踪更改 - 尝试将 BigClass 拆分为 SmallClass1 和 SmallClass2。对于 Perforce，BigClass 现在已不复存在，两个新类（SmallClass1 和 SmallClass2 已加入源代码树）。对于 Perforce，BigClass 与 SmallClass1 和 SmallClass2 之间没有关系。另一方面，Git 足够聪明，知道 x% 的 BigClass 现在在 SmallClass1 中，y% 的 BigClass 在 SmallClass2 中，而 BigClass 已不复存在。现在，从正在跨多个分支的更改的人的角度来看，您告诉我您认为哪种方法更有用——Git 的或 Perforce 的。就个人而言，我更喜欢 Git 的方法，因为它更准确地反映了代码中的实际更改。Git 能够这样做是因为它跟踪文件中的内容而不是文件本身。
13. 中心化或去中心化：Git 是一个DVCS系统，而 perforce 是中心化的。中心化的 VCS 以后不能去中心化，但 DVCS（尤其是 git）可以中心化。如果业务需要，有几种产品可以为 git 添加非常细粒度的访问控制。就我个人而言，从长远来看，我会选择一个能给我更大灵活性的系统。
14. 分支映射：如果你想在 Perforce 中直接进行分支，你需要创建一个分支映射。这是有原因的，但它们与 Perforce 如何概念化分支有关。作为开发人员或团队，这仅意味着工作流程中的多一步，我认为这根本没有效率。
15. 在团队之间共享工作：使用 Perforce，您无法拆分提交。团队 A 致力于功能 A。团队 B 致力于功能 B。团队 C 致力于错误修复。现在，团队 A 和 B 必须修复一堆错误才能实现他们的功能。唯一的问题是，他们在提交更改时并没有那么自律（可能是因为他们赶到最后期限），因此他们的“错误修复”是较大提交的一部分，其中还包含新内容，就其版本控制而言分行关心。但是，C 团队现在正在发布一个点，并希望从其他团队那里获得错误修复。如果他们使用 Git，C 团队可以挑选其他团队的相关更改，将它们拆分并只使用他们需要的内容，而不必担心引入任何部分实现的功能。使用 Perforce，
16. 更改平台 - 如果您将来出于任何原因决定更改您选择的平台，使用 Perforce，您将受到 Perforce.com 的摆布以及您选择的平台的工具的可用性。
17. 更改为未来惊人的源代码控制引擎 X - 如果您决定更改用于源代码控制的内容，从 Perforce 中提取源代码控制历史并将其移动到新系统 X 将是一场噩梦，因为它是封闭源代码并且是最好的你可以做的是猜测 - 只是谷歌 Perforce 到 Git 的迁移来了解我在说什么。至少对于 Git，它是开源的，所以它消除了很多涉及的猜测。

Well, that's my 2 cents. In Perforce's defense, I gotta say their customer support rules and so does their Time Lapse View tool. I do not know how to get a time lapse view with git. But for the convenience and time saved, I'd go with git any day.

嗯，这是我的 2 美分。在 Perforce 的辩护中，我必须说他们的客户支持规则，还有他们的 Time Lapse View 工具。我不知道如何使用 git 获得延时视图。但是为了方便和节省时间，我随时都会使用 git。

回答by Tim

It would take me a lot of convincing to switch from perforce. In the two companies I used it it was more than adequate. Those were both companies with disparate offices, but the offices were set up with plenty of infrastructure so there was no need to have the disjoint/disconnected features.

从 perforce 切换到我需要很多说服力。在我使用的两家公司中，它绰绰有余。这两家公司都设有不同的办公室，但这些办公室都配备了大量基础设施，因此无需具有脱节/脱节的功能。

How many developers are you talking about changing over?

你说有多少开发人员要换？

The real question is - what is it about perforce that is not meeting your organization's needs that git can provide? And similarly, what weaknesses does git have compared to perforce? If you can't answer that yourself then asking here won't help. You need to find a business case for your company. (e.g. Perhaps it is with lower overall cost of ownership (that includes loss of productivity for the interim learning stage, higher admin costs (at least initially), etc.)

真正的问题是 - perforce 无法满足 git 可以提供的组织需求的原因是什么？同样，与 perforce 相比，git 有哪些弱点？如果你自己不能回答这个问题，那么在这里问也无济于事。您需要为您的公司找到一个商业案例。（例如，也许它的总体拥有成本较低（包括临时学习阶段的生产力损失、较高的管理成本（至少最初）等）

I think you are in for a tough sell - perforce is a pretty good one to try to replace. It is a no brainer if you are trying to boot out pvcs or ssafe.

我认为你很难卖 - perforce 是一个很好的尝试替代的。如果您尝试启动 pvcs 或 ssafe，这很容易。

回答by tialaramex

I think in terms of keeping people happy during/ post switch over, one of things to get across early is just how private a local branch can be in Git, and how much freedom that gives them to make mistakes. Get them all to clone themselves a few private branches from the current code and then go wild in there, experimenting. Rename some files, check stuff in, merge things from another branch, rewind history, rebase one set of changes on top of another, and so on. Show how even their worst accidents locally have no consequences for their colleagues. What you want is a situation where developers feel safe, so they can learn faster (since Git has a steep learning curve that's important) and then eventually so that they're more effective as developers.

我认为就让人们在切换期间/切换后感到高兴而言，要尽早了解的一件事就是本地分支在 Git 中的私密性，以及给予他们犯错误的自由度。让他们全部从当前代码中克隆一些私有分支，然后在那里疯狂地进行试验。重命名一些文件，签入内容，合并来自另一个分支的内容，倒回历史记录，将一组更改重新设置在另一组之上，等等。展示即使在当地发生最严重的事故也不会对他们的同事造成任何后果。您想要的是一种让开发人员感到安全的情况，因此他们可以更快地学习（因为 Git 有一个陡峭的学习曲线，这很重要），然后最终使他们作为开发人员更有效。

When you're trying to learn a centralised tool, obviously you will be worried about making some goof that causes problems for other users of the repository. The fear of embarrassment alone is enough to discourage people from experimenting. Even having a special "training" repository doesn't help, because inevitably developers will encounter a situation in the production system that they never saw during training, and so they're back to worrying.

当您尝试学习一个集中式工具时，显然您会担心做一些会导致存储库其他用户出现问题的错误。仅对尴尬的恐惧就足以阻止人们进行实验。即使有一个特殊的“训练”存储库也无济于事，因为开发人员不可避免地会在生产系统中遇到他们在训练期间从未见过的情况，因此他们又开始担心了。

But Git's distributed nature does away with this. You can try any experiment in a local branch, and if it goes horribly wrong, just throw the branch away and nobody needs to know. Since you can create a local branch of anything, you can replicate a problem you're seeing with the real live repository, yet have no danger of "breaking the build" or otherwise making a fool of yourself. You can check absolutely everything in, as soon as you've done it, no trying to batch work up into neat little packages. So not just the two major code changes you spent four hours on today, but also that build fix that you remembered half way through, and the spelling mistake in the documentation you spotted while explaining something to a colleague, and so on. And if the major changes are abandoned because the project is changing direction, you can cherry pick the build fix and the spelling mistake out of your branch and keep those with no hassle.

但是 Git 的分布式特性消除了这一点。您可以在本地分支中尝试任何实验，如果出现严重错误，只需将分支扔掉，无需任何人知道。由于您可以创建任何内容的本地分支，因此您可以在真实的实时存储库中复制您看到的问题，而且没有“破坏构建”或以其他方式自欺欺人的危险。您可以在完成后立即检查所有内容，而无需尝试将工作批量打包成整洁的小包。因此，不仅是您今天花了四个小时进行的两个主要代码更改，还有您在中途记住的构建修复，以及您在向同事解释某事时发现的文档中的拼写错误，等等。如果因为项目正在改变方向而放弃了主要的变化，

回答by Thomas L Holaday

What Perforce features are people using?

人们正在使用哪些 Perforce 功能？

• Multiple workspaces on a single machine
• Numbered changelists
• Developer branches
• Integration with IDE (Visual Studio, Eclipse, SlickEdit, ...)
• Many build variants
• Composite workspaces
• Integrating some fixes but not others
• etc

• 一台机器上的多个工作区
• 编号的变更列表
• 开发者分支
• 与 IDE 集成（Visual Studio、Eclipse、SlickEdit 等）
• 许多构建变体
• 复合工作区
• 集成一些修复而不是其他修复
• 等等

I ask because if all folks are doing is get and put from the command line, git has that covered, and so do all the other RTS.

我问是因为如果所有人都在从命令行获取和放入，git 已经涵盖了这一点，所有其他 RTS 也是如此。

回答by Ryan

The command that sold me on git personally was bisect. I don't think that this feature is available in any other version control system as of now.

亲自在 git 上卖给我的命令是bisect。我认为到目前为止，此功能在任何其他版本控制系统中都不可用。

That being said, if people are used to a GUI client for source control they are not going to be impressed with git. Right now the only full-featured client is command-line.

话虽如此，如果人们习惯于使用 GUI 客户端进行源代码控制，他们将不会对 git 印象深刻。现在唯一的全功能客户端是命令行。

回答by Aristotle Pagaltzis

Apparently GitHub now offer git training courses to companies. Quoth their blog post about it:

显然GitHub 现在向公司提供 git 培训课程。引用他们的博客文章：

I've been down to the Google campus a number of times in the last few weeks helping to train the Androids there in Git. I was asked by Shawn Pearce (you may know him from his Git and EGit/JGit glory – he is the hero that takes over maintanance when Junio is out of town) to come in to help him train the Google engineers working on Andriod in transitioning from Perforce to Git, so Android could be shared with the masses. I can tell you I was more than happy to do it.

[…]

Logical Awesome is now officially offeringthis type of custom training service to all companies, where we can help your organization with training and planning if you are thinking about switching to Git as well.

在过去的几周里，我多次来到 Google 园区，帮助在那里用 Git 培训 Android。Shawn Pearce（你可能从他的 Git 和 EGit/JGit 荣耀中认识他 - 他是当 Junio 出城时接管维护工作的英雄）来帮助他培训 Google 工程师在过渡中工作从 Perforce 到 Git，因此 Android 可以与大众共享。我可以告诉你，我非常乐意这样做。

[…]

Logical Awesome 现在正式向所有公司提供这种类型的定制培训服务，如果您也考虑切换到 Git，我们可以帮助您的组织进行培训和规划。

Emphasis mine.

强调我的。

回答by user389238

I have been using Perforce for a long time and recently I also started to use GIT. Here is my "objective" opinion:

我使用 Perforce 已经很长时间了，最​​近我也开始使用 GIT。这是我的“客观”意见：

Perforce features:

性能特点：

1. GUI tools seem to be more feature rich (e.g. Time lapse view, Revision graph)
2. Speed when syncing to head revision (no overhead of transferring whole history)
3. Eclipse/Visual Studio Integration is really nice
4. You can develop multiple features in one branch per Changelist (I am still not 100% sure if this is an advantage over GIT)
5. You can "spy" what other developers are doing - what kind of files they have checked out.

1. GUI 工具似乎功能更丰富（例如时间推移视图、修订图）
2. 同步到头部修订时的速度（没有传输整个历史的开销）
3. Eclipse/Visual Studio 集成非常好
4. 您可以在每个 Changelist 的一个分支中开发多个功能（我仍然不能 100% 确定这是否比 GIT 有优势）
5. 您可以“窥探”其他开发人员在做什么——他们签出了什么样的文件。

GIT features:

GIT 特点：

1. I got impressions that GIT command line is much simpler than Perforce (init/clone, add, commit. No configuration of complex Workspaces)
2. Speed when accessing project history after a checkout (comes at a cost of copying whole history when syncing)
3. Offline mode (developers will not complain that unreachable P4 server will prohibit them from coding)
4. Creating a new branches is much faster
5. The "main" GIT server does not need plenty of TBytes of storage, because each developer can have it's own local sandbox
6. GIT is OpenSource - no Licensing fees
7. If your Company is contributing also to OpenSource projects then sharing patches is way much easier with GIT

1. 我的印象是 GIT 命令行比 Perforce 简单得多（初始化/克隆、添加、提交。无需配置复杂的工作区）
2. 结帐后访问项目历史记录的速度（以同步时复制整个历史记录为代价）
3. 离线模式（开发者不会抱怨无法访问的 P4 服务器会禁止他们编码）
4. 创建新分支要快得多
5. “主”GIT 服务器不需要大量 TBytes 的存储空间，因为每个开发人员都可以拥有自己的本地沙箱
6. GIT 是开源的 - 没有许可费用
7. 如果您的公司也在为开源项目做出贡献，那么使用 GIT 共享补丁会容易得多

Overall for OpenSource/Distributed projects I would always recommend GIT, because it is more like a P2P application and everyone can participate in development. For example, I remember that when I was doing remote development with Perforce I was syncing 4GB Projects over 1Mbps link once in a week. Alot of time was simply wasted because of that. Also we needed set up VPN to do that.

总的来说，对于开源/分布式项目，我总是推荐 GIT，因为它更像是一个 P2P 应用程序，每个人都可以参与开发。例如，我记得当我使用 Perforce 进行远程开发时，我每周通过 1Mbps 链接同步 4GB 项目。很多时间只是因此而浪费了。我们还需要设置 VPN 来做到这一点。

If you have a small company and P4 server will be always up then I would say that Perforce is also a very good option.

如果您有一家小公司并且 P4 服务器将始终运行，那么我会说 Perforce 也是一个非常好的选择。

回答by Prakash Nadar

We have been using Git for sometime, recently our Git server's harddrive crashed and we could not revert back to the latest state. We managed to get back to few days old state. When the server was back up. Everyone in the team pulled/pushed their changes and voila, the server is back to current state.

我们一直在使用 Git，最近我们的 Git 服务器的硬盘崩溃了，我们无法恢复到最新状态。我们设法回到了几天前的状态。当服务器备份时。团队中的每个人都拉/推了他们的更改，瞧，服务器恢复到当前状态。

回答by pjnlsn

The one important difference between Perforce and git (and the one most commonly mentioned) is their respective handling of huge binary files.

Perforce 和 git（也是最常提到的那个）之间的一个重要区别是它们各自处理巨大的二进制文件。

Like, for example, in this blog of an employee at a video game development company: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

例如，在视频游戏开发公司的一名员工的博客中：http: //corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

However, the important thing is that, the speed difference between git and perforce, when you have a huge 6gb repository, containing everything from documentation to every binary ever built (and finally, oh yes! the actual source history), usually comes from the fact that huge companies tend to run Perforce, and so they set it up to offload all significant operations to the huge server bank in the basement.

然而，重要的是，git 和 perforce 之间的速度差异，当你有一个巨大的 6gb 存储库，包含从文档到曾经构建的每个二进制文件的所有内容（最后，哦，是的！实际的源历史），通常来自事实上，大公司倾向于运行 Perforce，因此他们将其设置为将所有重要操作卸载到地下室的大型服务器银行。

This important advantage on Perforce's part comes only from a factor that has nothing whatsoever to do with Perforce, the fact that the company running it can afford said server bank.

Perforce 的这一重要优势仅来自与 Perforce 无关的一个因素，即运行它的公司能够负担得起所述服务器银行。

And, anyway, in the end, Perforce and git are different products. Git was designed to be solely a VCS, and it does this far better than Perforce (in that it has more features, which are generally easier to use, in particular, in the words of another, branching in Perforce is like performing open-heart surgery, it should only be done by experts :P ) ( http://stevehanov.ca/blog/index.php?id=50)

而且，无论如何，归根结底，Perforce 和 git 是不同的产品。Git 被设计为单独的 VCS，它比 Perforce 做得好得多（因为它有更多的特性，通常更容易使用，特别是，用另一个的话来说，在 Perforce 中分支就像执行开放的心手术，只能由专家来做 :P ) ( http://stevehanov.ca/blog/index.php?id=50)

Any other benefits which companies that use Perforce gain have come merely because Perforce is not solely a VCS, it's also a fileserver, as well as having a host of other features for testing the performance of builds, etc.

使用 Perforce 的公司获得的任何其他好处仅仅是因为 Perforce 不仅仅是一个 VCS，它还是一个文件服务器，以及具有许多其他用于测试构建性能的功能等。

Finally: Git being open-source and far more flexible to boot, it would not be so hard to patch git to offload important operations to a central server, running mounds of expensive hardware.

最后：Git 是开源的并且启动起来更加灵活，因此修补 git 以将重要操作卸载到运行大量昂贵硬件的中央服务器并不难。