实际上是如何进行的？它是从服务器获取差异并应用em，还是服务器只发送一个文件的最新版本（它是否被压缩？）然后与我的本地文件合并？
我问因为afaik，在git中每个文件修订都是blob，所以我希望当我执行git pull时它会从服务器获取blob而不是差异。
真正的问题是理论上更快的svn up或git pull？ （当然这取决于回购规模和回购的变化，但我们只考虑网络流量）
提前致谢
答案 0 :(得分：4)
svn up确定工作副本中文件的基本修订版，并将其传达给服务器。服务器将使用该知识来计算要发送回的文件的deltafied版本。然后应用增量来获得新的工作基础，差异也应用于您的工作副本。
这里有更多的东西，在某些情况下会有一些优化，但在最基本的层面上，这就是正在发生的事情。它有点复杂，因为Subversion支持混合修订工作副本。这是在不同版本中具有树的不同部分的工作副本。
git pull有点不同。由于Git不支持混合修订工作副本，因此它实际上只关心您当前所处的提交。因此git将传达其引用（分支）的当前状态，然后服务器将计算需要发送哪些提交，打包并将它们发送到客户端。一旦新提交在客户端上，则更新远程引用并尝试将新内容与工作副本合并。
从高级视图来看，我认为两者非常相似：他们计算“差异”，压缩它们，并将它们发送到客户端。但细节差别很大。整个文件内容不一定与任何一个一起发送。
我认为git pull有一点网络效率，原因如下：
GIT中永远只需要进行通信的分支的SHA1，而Subversion需要抓取整个树被更新和通信是比工作树的基部不同修订版树的部分（这是常见的是颠覆）。后一位也意味着还有更多的磁盘I / O - 尽管在最新版本的Subversion中它已经得到了很大的改进。
Git通常可以更好地对齐内容，这意味着它通常可以更好地压缩数据。
Git可以更好地跟踪和传达内容。因此，如果你在Git中有一个文件的三个副本，它只会传递一个blob来表示该文件，而Subversion会传达三个。
OTOH，您可以选择仅更新Subversion中的部分树。如果你有许多开发人员在代码库上工作，并且存储库中存在大量活动，并且你的部分相当孤立，那么你只能在你关心的树中svn up而不必担心抓住其他位直到你准备好了。 Git仅适用于存储库，不支持混合修订工作副本，因此它需要获取所有提交 - 这可能是相当多的数据。
所以，最后，它可能取决于您的用例以及对您来说重要的事情。但总的来说，我相信Git占上风。
答案 1 :(得分：1)
Git存储blob，但传递差异。 Git非常有效地这样做。从服务器git获取更改首先确定服务器和客户端之间的差异并传达包。包是获取git和服务器git之间的一种压缩差异。它还非常有效地处理大型二进制文件。