GIT与Perforce-两个VCS将进入…一个将离开
所以我正在把GIT卖掉。 我需要的第一件事就是让每个人都相信，GIT在他们已经习惯的方面做得更好。 我们目前使用Perforce。 其他人经历了类似的销售？ 任何好的链接/build议？
其中一个重大胜利就是我们可以使用与networking断开的连接。 另一个赢得国际海事组织是方式添加/结帐处理。 多点欢迎！ 另外我们总共有10-20个开发者。
Perl 5解释器源代码目前正在经历从Perforce转换为git的痛苦。 也许Sam Vilain的git-p4rawimport商很感兴趣。
无论如何，对于每个集中式VCS和大多数分布式VCS来说，主要的胜利之一就是速度快 ， 速度快 。 你无法想象如何将整个项目的历史放在眼前，仅仅只有几分之一秒的时间，直到你经历过它。 即使生成整个项目历史的提交日志，其中包含每个提交的完整差异可以在几分之一秒内测量。 Git太快了，你的帽子会飞走。 必须通过networking来回传输的VCS根本没有竞争的机会，甚至不能通过千兆以太网链路。
另外，git在提交时很容易被仔细select，因此允许工作副本（甚至在单个文件中）的更改分散在多个提交 – 如果需要的话跨越不同的分支。 这可以让你在工作的时候减less思维注意力 – 你不需要如此谨慎地计划你的工作，决定你要做什么样的改变，并确保推迟其他事情。 你可以随意做出你想要的任何改变，而且当它提交的时候，仍然可以解开它们 – 几乎总是很容易的。 藏匿在这里可以是一个非常大的帮助。
我发现，这些事实一起使我自然而然地做出比以前使用git更多，更集中的提交。 这反过来不仅使你的历史一般更有用，但特别有利于增值工具，如git bisect 。
我相信现在还有更多的事情我想不出来。 在git上销售你的团队的一个问题是，许多好处是相互关联的，正如我在上面所暗示的，这样很难简单地看一下git的特性和好处列表，并推断出它们是如何将会改变你的工作stream程，而哪些改变将会是真正的改进。 你需要考虑到这一点，你也需要明确指出。
我在工作中使用Perforce。 我也使用Git，因为当我正在处理代码并且无法连接到服务器时，仍然会喜欢某种forms的版本控制。 不，调和离线工作是不一样的。 这里是我发现git是一个很大的好处：
- 分支速度 – git最多需要几秒钟的时间。
- 冲突 – P4Merge的自动化解决scheme一度摧毁了一周的工作。 从那以后，我宁愿在合并时手动解决。 当Git提示我发生冲突时，实际上是冲突。 剩下的时间，git正确地解决问题，我节省了大量的时间。
- 跟踪合并 – 如果您有一个分支持续接收来自其他两个分支的合并，那么您知道这可能会令人头痛。 使用git，头痛被最小化了，因为git合并的结果实际上是一个新的提交，它知道它的祖先是谁。
- 权限 – 我已经失去了试图处理文件的次数，但不能在Perforce中检出。 如果你使用XCode（或者没有一个可靠的Perforce SCM插件的编辑器）离线工作，你就会知道这有多刺激。 我不必担心与Git。 我做了我的改变。 Git不会阻止我并在后台跟踪它们。
- 保持主树整洁 – 用git，我可以把我的提交和整理代码，使历史看起来不错，整齐。 没有一个“检查这个文件，因为它应该是以前签入垃圾的一部分”。 我压扁这样做，因为他们帮助没有人。
- 存储 – 您的执行服务器需要版本2010.1或更新版本才能使用p4 shelve命令。
- 创build补丁 – 容易在git中完成。 不知道在Perforce中是否可以不使用命令行。
- 从GUI邮寄补丁 – 再一次，git在这里获胜。
- 磁盘空间 – 使用perforce，每个分支都是一个副本。 这意味着如果你的源代码树很大，你的磁盘空间就会被吃掉。 一旦你开始build设，这甚至不计算额外的空间。 为什么即使分支和磁盘空间之间有链接？ 用git，你可以有100个分支，一次只有一个分支。 如果你特别想同时在两个版本上工作，你可以克隆，做你的工作，然后摆脱一个克隆，如果你想，而不会丢失任何东西。
- 如果你使用的是XCode4，那么perforce的支持已经被删除了，而git的支持现在已经被内置了。如果你像我一样跨平台的工作，这个问题很重要。 使用Visual Studio，你可以使用git扩展。 用perforce，这两个操作系统都同样恶作剧。 好吧，也许现在用XCode4在现场的Mac上多一点。
- 发现错误的签入（或，git bisect规则） – 曾经尝试使用perforce进行二进制search以找出引入错误的位置？ 很麻烦，是吗？ 从中间的其他分支整合起来更是一件麻烦事。 为什么？ 因为这样的任务没有自动化。 你需要编写自己的工具来和perforce交谈，而且你通常没有时间。 使用git，你可以给出它的出发点（“好”点和“坏”点），并自动为你search。 更好的是，如果你有一个脚本可以使构build和testing过程自动化，你可以把git钩到脚本上，并且findcheckin的整个过程都是自动的。 这是应该的。
- 跟踪重构中的变化 – 尝试将BigClass分成SmallClass1和SmallClass2。 对于Perforce，BigClass现在已经不复存在，并且有两个新的类（SmallClass1和SmallClass2已经join了源码树）。 对于Perforce，BigClass和SmallClass1和SmallClass2之间没有关系。 另一方面，Git足够聪明地知道BigClass的x％现在在SmallClass1中，而BigClass的y％在SmallClass2中，并且BigClass已经不存在了。 现在，从正在审查多个分支变化的人的angular度来看，您告诉我哪种方法更有用 – Git或Perforce。 就个人而言，我更喜欢Git的方法，因为它更准确地反映了代码中的实际更改。 Git能够做到这一点，因为它跟踪文件内的内容，而不是文件本身。
- 集中式或分散式：Git是一个DVCS系统，而集中式执行。 一个集中的VCS以后不能分散，而是一个DVCS（尤其是git）可以集中。 有几种产品为git添加了非常细致的访问控制，如果这是业务需要的东西。 就我个人而言，我会采用一个让我在长期内更有弹性的系统。
- 分支映射：如果你想在Perforce中分支，你需要创build一个分支映射。 这是有原因的，但是它们与Perforce如何将分支概念化有关。 作为一个开发人员，或者一个团队，这只是意味着工作stream程中的一个更进一步的步骤，我根本没有考虑到这一点。
- 在团队之间共享工作：使用Perforce，你不能分解提交。 团队A正在研究特性A.团队B正在研究特性B.团队C正在研究bug修复。 现在，团队A和B必须修复一些错误才能实现其function。 唯一的一点是，他们在提交更改时没有受到严格的规定（可能是因为他们正赶到最后期限），所以他们的“错误修复”是较大的提交内容的一部分，也包含了新的内容，分支机构。 然而，Team C现在正在发布一个点，并希望从其他团队获得错误修复。 如果他们使用的是Git，C队可以select其他团队的相关变化，将他们分开，只需要他们所需要的，而不用担心引入任何部分实施的function。 使用Perforce，团队C可以获取受影响的文件，但必须使用更为人工的过程来分离相关更改。
- 不断变化的平台 – 无论出于何种原因，如果您决定使用Perforce来改变您的select平台，那么您将受到Perforce.com的支配，以及您select的平台工具的可用性。
- 更改为未来的惊人的源代码控制引擎X – 如果您决定更改源代码pipe理的用途，从Perforce提取源代码pipe理历史logging并将其移至新的系统X将会是一场噩梦，因为它是封闭的源代码，你可以做的只是猜测 – 只要谷歌的Perforce到Git迁移来了解我在说什么。 至lessGit是开源的，所以它消除了大量的猜测。
那么，这是我的2美分。 在Perforce的辩护中，我必须说明他们的客户支持规则，他们的Time Lapse View工具也是如此。 我不知道如何用git获得时间延迟视图。 但为了节省方便和时间，我会随时与git一起去。
从执行中切换会让我很有说服力。 在我使用它的两家公司中，这已经足够了。 这两家公司都有不同的办事处，但办公室的基础设施充足，所以不需要有不相干/不相连的function。
你有多less开发者在谈论改变？
真正的问题是，什么是不符合你的组织的需求，git可以提供？ 同样，git和perforce相比有什么缺点？ 如果你不能自己回答，那么在这里询问将无济于事。 你需要find你的公司的商业案例。 （例如，也许总体拥有成本较低（包括临时学习阶段的生产力损失，pipe理成本较高（至less在初始阶段）等）
我认为你是一个艰难的销售 – 执行力是一个很好的尝试取代。 如果你试图启动pvcs或ssafe，这是不容易的。
我认为，在转换过程中保持人们的幸福感，早期得到的一个东西就是Git中一个本地分支机构的私密性，以及犯错误的自由度。 让他们都从当前的代码克隆自己的一些私人分支，然后在那里疯狂，试验。 重命名一些文件，检查内容，合并另一个分支的内容，重放历史logging，重新设置一组更改，等等。 显示他们在当地最严重的事故甚至对他们的同事没有任何影响。 你想要的是开发人员感到安全的情况，所以他们可以更快地学习（因为Git有一个陡峭的学习曲线，这很重要），最终使他们作为开发人员更有效。
当你试图学习一个集中的工具时，显然你会担心会造成一些问题，导致版本库的其他用户出现问题。 单单担心尴尬就足以阻止人们进行实验。 即使有一个特殊的“培训”存储库也没有帮助，因为开发人员不可避免地会遇到在培训过程中从未见过的生产系统中的情况，所以他们再次担心。
但是Git的分布式性质消除了这一点。 你可以在当地的一家分店尝试任何实验，如果发生了可怕的错误，就把分支扔掉，没有人需要知道。 既然你可以创build一个任何东西的本地分支，你可以用真实的存储库复制一个你正在看到的问题，但是没有“破坏构build”的危险，否则你自己就变傻了。 你可以检查一切，只要你做完了，不要试图批量处理整齐的小包装。 因此，不仅仅是您今天花了四个小时的两个主要代码更改，还包括您记住一半的修复，以及在向同事解释某些内容时发现的文档中的拼写错误等等。 而如果因为项目正在改变方向而放弃重大更改，则可以从分支中挑选构build修补程序和拼写错误，并保持不变。
亲自把我卖给git的命令是平分的 。 我不认为这个function在任何其他版本控制系统中都是可用的。
话虽如此，如果人们习惯于GUI客户端的源代码控制，他们不会被git留下深刻的印象。 现在唯一的全function客户端是命令行。
人们使用哪些Perforcefunction？
- 一台机器上有多个工作区
- 编号的更改表
- 开发者分支
- 与IDE集成（Visual Studio，Eclipse，SlickEdit等）
- 许多构build变体
- 复合工作区
- 集成一些修复，但不是其他的
- 等等
我问，因为如果所有人都在做的是从命令行取得和放，git有覆盖，所有其他RTS也是如此。
显然GitHub现在为公司提供git培训课程 。 请他们的博客文章 ：
在过去几周里，我一直在Google校园里帮助培训Git中的Android。 我被肖恩·皮尔斯（Shawn Pearce）问过（你可以从他的Git和EGit / JGit的荣耀中知道他 – 他是在Junio不在的时候接pipe了主angular的英雄）来帮助他训练从事Andriod的Google工程师的过渡从Perforce到Git ，所以Android可以与大众共享。 我可以告诉你，我非常乐意这样做。
[…]
Logical Awesome现在正式向所有公司提供这种types的定制培训服务，如果您正在考虑切换到Git，我们可以帮助您的组织进行培训和规划。
强调我的。
我一直在使用Perforce很久，最近我也开始使用GIT。 这是我的“客观”意见：
Perforcefunction：
- GUI工具似乎更丰富（例如时间推移视图，修订图）
- 同步到主版本时的速度（没有传输整个历史的开销）
- Eclipse / Visual Studio集成非常好
- 您可以在一个分支中为每个Changelist开发多个function（我还不能100％确定这是否比GIT有优势）
- 你可以“窥探”其他开发者在做什么 – 他们已经检出了哪种文件。
GITfunction：
- 我觉得GIT命令行比Perforce简单得多（init / clone，add，commit。没有configuration复杂的工作空间）
- 在结帐后访问项目历史logging时的速度（以同步时复制整个历史logging为代价）
- 离线模式（开发人员不会抱怨，无法访问的P4服务器将禁止他们编码）
- 创build一个新的分支要快得多
- “主”GIT服务器不需要大量的存储空间，因为每个开发人员都可以拥有自己的本地沙箱
- GIT是开源的 – 没有授权费用
- 如果您的公司也在为OpenSource项目做出贡献，那么使用GIT共享补丁程序要容易得多
总的来说，对于开源/分布式项目，我总是推荐GIT，因为它更像是一个P2P应用程序，每个人都可以参与开发。 例如，我记得当我使用Perforce进行远程开发时，我在一周内一次同步4GB项目1Mbps以上的链接。 很多时间都是因为这个而浪费掉的。 我们还需要build立VPN来做到这一点。
如果你有一个小公司和P4服务器将永远，那么我会说，Perforce也是一个非常好的select。
我们一直在使用Git，最近我们的Git服务器的硬盘崩溃了，我们无法恢复到最新的状态。 我们设法回到几天前的状态。 当服务器备份时。 团队中的每个人都推动/推动他们的变化，瞧，服务器回到当前状态。
Perforce和git之间的一个重要的区别（和最常提到的）是它们各自处理巨大的二进制文件。
例如，在这个video游戏开发公司的员工博客中： http : //corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
然而，重要的是，git和perforce之间的速度差异，当你有一个巨大的6GB版本库，包含从文档到每个二进制文件（最后，哦，是的！实际的源历史logging）的所有内容时，通常来自事实上，大公司倾向于运行Perforce，所以他们将所有重要的操作卸载到地下室的大型服务器银行。
Perforce的这个重要优势只是来自于与Perforce没有任何关系的因素，运行它的公司可以承担所述服务器银行的事实。
而且，无论如何，最后，Perforce和git是不同的产品。 Git被devise成只是一个VCS，并且它比Perforce要好得多（因为它具有更多的特性，通常更容易使用，特别是用另一个语言来说，Perforce中的分支就像开放式心脏手术只能由专家来完成：P）（ http://stevehanov.ca/blog/index.php?id=50 ）
使用Perforce的公司获得的其他好处仅仅是因为Perforce不仅仅是一个VCS，它也是一个文件服务器，还有许多其他function来testing构build的性能等等。
最后：Git是开源的，而且启动起来要灵活得多，要把git卸载到中央服务器，运行一堆昂贵的硬件，并不是那么难。
我认为GIT赢得的一件事就是它能够在所有文件中“保留行结束”，而perforce似乎坚持把它们转换成Unix，Dos / Windows或MacOS9格式（“\ n”，“\ r \ n“或”\ r）。
如果您在Windows环境或混合操作系统环境中编写Unix脚本，这是一个真正的痛苦。 甚至不可能在每个文件扩展名的基础上设置规则。 例如，它会将.sh，.bash，.unix文件转换为Unix格式，并将.ccp，.bat或.com文件转换为Dos / Windows格式。
在GIT（我不知道这是默认的，一个选项或唯一的select），你可以设置为“保留行结束”。 这意味着，您可以手动更改文件的行结尾，然后GIT将按原样保留该格式。 在我看来，这似乎是理想的做事方式，我不明白为什么这不是Perforce的select。
您可以实现此行为的唯一方法是将文件标记为二进制文件。 正如我所看到的，这将是一个讨厌的黑客来解决缺less的function。 除了在所有的脚本上不得不做的繁琐之外，它也可能会破坏大部分的差异等等。
目前我们已经解决的“解决scheme”是运行一个sed命令，每次将它们部署到Unix环境时，从脚本中删除所有回车。 这也不是很理想，尤其是因为它们中的一部分被部署在WAR文件中，并且sed行在解包时必须重新运行。
这只是我认为给GIT一个很大的优势，而我认为上面没有提到。
编辑：在使用了一段时间的Perforce之后，我想再添加一些评论：
A）我在Perforce中真的很想念的是一个清晰的实例比较，包括更改，删除和添加文件。 这在git diff中可以通过git diff命令获得，但是在Perforce中，文件必须在logging更改之前检出，并且可以让主编辑器（如Eclipse）设置为在编辑时自动检出文件，你有时可能以其他方式编辑文件（记事本，Unix命令等）。 而且新文件似乎不会自动添加，甚至使用Eclipse和p4eclipse，这可能是相当烦人的。 所以为了find所有的变化，你必须在整个工作空间上运行一个“Diff …”，首先需要一段时间才能运行，其次包括所有不相关的东西，除非你设置了非常复杂的排除列表，这导致我到下一个点。
B）在GIT中，我发现.gitignore非常简单，易于pipe理，阅读和理解。 但是，在Perforce中configuration的工作空间忽略/排除列表看起来很笨重且不必要的复杂。 使用通配符的工作我一直没有得到排除。 我想做类似的事情
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
要排除Server / mainline内所有项目中的所有目标文件夹。 但是，这似乎并不像我预期的那样工作，而且我最终为每个项目添加了一行：
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/... -//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/... ...
和bin文件夹，.classpath和.projet文件等类似的行。
C）在Perforce中有相当有用的变更表。 但是，假设我做了一组更改，将其全部检查并放入更改列表中，然后再提交其他更改列表。 如果稍后对第一个更改列表中包含的某个文件进行更改，该文件仍将位于该更改列表中，并且我不能稍后提交更改列表，前提是它只包含我最初添加的更改（尽pipe它将是相同的文件）。 在GIT中，如果你添加了一个文件，并且对它进行了进一步的修改，那么这些修改就不会被添加（并且仍然会显示在一个git diff并且你不能在没有首先添加新的修改的情况下提交文件当然，这与变更列表的变化无关，因为你只有一组添加的文件，但是在GIT中，你可以提交变更，因为这实际上并不推动变更，你可以在推动其他更改之前先处理其他更改，但是如果不更新以前的更改，则无法再推送其他任何更新。
I have no experience with Git, but I have with Mercurial which is also a distributed VCS. It depends on the project really, but in our case a distributed VCS suited the project as basically eliminated frequent broken builds.
I think it depends on the project really, as some are better suited towards a client-server VCS, and others towads a distributed one.
Here's what I don't like about git:
First of all, I think the distributed idea flies in the face of reality. Everybody who's actually using git is doing so in a centralised way, even Linus Torvalds. If the kernel was managed in a distributed way, that would mean I couldn't actually download the "official" kernel sources – there wouldn't be one – I'd have to decide whether I want Linus' version, or Joe's version, or Bill's version. That would obviously be ridiculous, and that's why there is an official definition which Linus controls using a centralised workflow.
If you accept that you want a centralised definition of your stuff, then it becomes clear that the server and client roles are completely different, so the dogma that the client and server softwares should be the same becomes purely limiting. The dogma that the client and server data should be the same becomes patently ridiculous, especially in a codebase that's got fifteen years of history that nobody cares about but everybody would have to clone.
What we actually want to do with all that old stuff is bung it in a cupboard and forget that it's there, just like any normal VCS does. The fact that git hauls it all back and forth over the network every day is very dangerous, because it nags you to prune it. That pruning involves a lot of tedious decisions and it can go wrong. So people will probably keep a whole series of snapshot repos from various points in history, but wasn't that what source control was for in the first place? This problem didn't exist until somebody invented the distributed model.
Git actively encourages people to rewrite history, and the above is probably one reason for that. Every normal VCS makes rewriting history impossible for all but the admins, and makes sure the admins have no reason to consider it. Correct me if I'm wrong, but as far as I know, git provides no way to grant normal users write access but ban them from rewriting history. That means any developer with a grudge (or who was still struggling with the learning curve) could trash the whole codebase. How do we tighten that one? Well, either you make regular backups of the entire history, ie you keep history squared, or you ban write access to all except some poor sod who would receive all the diffs by email and merge them by hand.
Let's take an example of a well-funded, large project and see how git is working for them: Android. I once decided to have a play with the android system itself. I found out that I was supposed to use a bunch of scripts called repo to get at their git. Some of repo runs on the client and some on the server, but both, by their very existence, are illustrating the fact that git is incomplete in either capacity. What happened is that I was unable to pull the sources for about a week and then gave up altogether. I would have had to pull a truly vast amount of data from several different repositories, but the server was completely overloaded with people like me. Repo was timing out and was unable to resume from where it had timed out. If git is so distributable, you'd have thought that they'd have done some kind of peer-to-peer thing to relieve the load on that one server. Git is distributable, but it's not a server. Git+repo is a server, but repo is not distributable cos it's just an ad-hoc collection of hacks.
A similar illustration of git's inadequacy is gitolite (and its ancestor which apparently didn't work out so well.) Gitolite describes its job as easing the deployment of a git server. Again, the very existence of this thing proves that git is not a server, any more than it is a client. What's more, it never will be, because if it grew into either it would be betraying it's founding principles.
Even if you did believe in the distributed thing, git would still be a mess. What, for instance, is a branch? They say that you implicitly make a branch every time you clone a repository, but that can't be the same thing as a branch in a single repository. So that's at least two different things being referred to as branches. But then, you can also rewind in a repo and just start editing. Is that like the second type of branch, or something different again? Maybe it depends what type of repo you've got – oh yes – apparently the repo is not a very clear concept either. There are normal ones and bare ones. You can't push to a normal one because the bare part might get out of sync with its source tree. But you can't cvsimport to a bare one cos they didn't think of that. So you have to cvsimport to a normal one, clone that to a bare one which developers hit, and cvsexport that to a cvs working copy which still has to be checked into cvs. Who can be bothered? Where did all these complications come from? From the distributed idea itself. I ditched gitolite in the end because it was imposing even more of these restrictions on me.
Git says that branching should be light, but many companies already have a serious rogue branch problem so I'd have thought that branching should be a momentous decision with strict policing. This is where perforce really shines…
In perforce you rarely need branches because you can juggle changesets in a very agile way. For instance, the usual workflow is that you sync to the last known good version on mainline, then write your feature. Whenever you attempt to modify a file, the diff of that file gets added to your "default changeset". When you attempt to check in the changeset, it automatically tries to merge the news from mainline into your changeset (effectively rebasing it) and then commits. This workflow is enforced without you even needing to understand it. Mainline thus collects a history of changes which you can quite easily cherry pick your way through later. For instance, suppose you want to revert an old one, say, the one before the one before last. You sync to the moment before the offending change, mark the affected files as part of the changeset, sync to the moment after and merge with "always mine". (There was something very interesting there: syncing doesn't mean having the same thing – if a file is editable (ie in an active changeset) it won't be clobbered by the sync but marked as due for resolving.) Now you have a changelist that undoes the offending one. Merge in the subsequent news and you have a changelist that you can plop on top of mainline to have the desired effect. At no point did we rewrite any history.
Now, supposing half way through this process, somebody runs up to you and tells you to drop everything and fix some bug. You just give your default changelist a name (a number actually) then "suspend" it, fix the bug in the now empty default changelist, commit it, and resume the named changelist. It's typical to have several changelists suspended at a time where you try different things out. It's easy and private. You get what you really want from a branch regime without the temptation to procrastinate or chicken out of merging to mainline.
I suppose it would be theoretically possible to do something similar in git, but git makes practically anything possible rather than asserting a workflow we approve of. The centralised model is a bunch of valid simplifications relative to the distributed model which is an invalid generalisation. It's so overgeneralised that it basically expects you to implement source control on top of it, as repo does.
The other thing is replication. In git, anything is possible so you have to figure it out for yourself. In perforce, you get an effectively stateless cache. The only configuration it needs to know is where the master is, and the clients can point at either the master or the cache at their discretion. That's a five minute job and it can't go wrong.
You've also got triggers and customisable forms for asserting code reviews, bugzilla references etc, and of course, you have branches for when you actually need them. It's not clearcase, but it's close, and it's dead easy to set up and maintain.
All in all, I think that if you know you're going to work in a centralised way, which everybody does, you might as well use a tool that was designed with that in mind. Git is overrated because of Linus' fearsome wit together with peoples' tendency to follow each other around like sheep, but its main raison d'etre doesn't actually stand up to common sense, and by following it, git ties its own hands with the two huge dogmas that (a) the software and (b) the data have to be the same at both client and server, and that will always make it complicated and lame at the centralised job.
Using GIT as substitute for bad code line management is common. Many of the disadvantages of Perforce are a result of bad branching strategies. The same for any other centralized tool. If you have to create a ton of branches you are doing something wrong. Why do developers need to create so many branches?
Also, why is working disconnected so important anyway? Just so someone can work on a train? That's about the only place these days you can't get a wireless connection. And even most trains have decent WiFi.
