回购同步挂起
我试图获取 Android 1.6 版本的源代码，但是存储库 同步操作保持挂起。
我将在终端上收到的消息的最后部分粘贴在这里：
Fetching projects: 19% (32/164)
Initializing project platform/external/freetype ...
remote: Counting objects: 970, done.
remote: Compressing objects: 100% (414/414), done.
Receiving objects: 57% (558/970), 1.28 MiB | 26 KiB/s
它只是挂在那里......没有错误消息或任何此类内容。
有人遇到过类似的问题吗？
I was trying to get the sources for the Android 1.6 release, but the repo
sync operation keeps hanging.
I am pasting the last part of the message i get on the terminal here:
Fetching projects: 19% (32/164)
Initializing project platform/external/freetype ...
remote: Counting objects: 970, done.
remote: Compressing objects: 100% (414/414), done.
Receiving objects: 57% (558/970), 1.28 MiB | 26 KiB/s
It just hangs there... no error messages or aything of that sort.
Has anyone faced a similar issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想知道你是否使用VMWare来运行Linux。我遇到了和你一样的问题，直到我找到原因：我们这边的 tcp 窗口大小设置为 0（完整）。我在 Windows 7 64 位的 VMWare 上运行 Ubuntu 10.04 作为主机。要修复它，只需确保为 VMWare 上的 Ubuntu 提供足够的 RAM，以消除任何内存问题。我将我的设置为 512MB，并增加到 1.5M 以获得更好的性能。然后是最重要的设置（也是真正发挥作用的设置）：确保将 VMWare 上的网络适配器设置为桥接模式。例如，如果使用 NAT，NAT 服务将会阻塞并扰乱您的窗口大小。
原因：
客户端的 TCP 窗口大小告诉服务器它愿意一次从服务器接收的字节数；这是客户端的接收窗口。当窗口设置为 0 时，意味着客户端将无法接收更多数据，直到处理完内部缓冲区中仍待处理的任何数据。这是正常的 TCP 内容。在客户端上将窗口设置为 0 的大小效果是，TCP 连接仍将保持活动状态一段时间，直到服务器确定其已等待足够时间并终止该连接。这就是导致我的存储库同步挂起而没有错误的原因。
I wonder if you are using VMWare to run Linux. I experienced the same problem as you until I've found what was causing it: the tcp window size on our side being set to 0 (full). I am running Ubuntu 10.04 on VMWare on Windows 7 64-bit as host. To fix it just make sure you give plenty of RAM to Ubuntu on VMWare to discard any memory issues. I had mine set to 512MB and increase it to 1.5M for better performance. Then the most important setting (and the one that did the trick actually): make sure you set the network adapter on VMWare to bridged mode. If using NAT for example, the NAT service will choke and mess the window size for you.
Cause:
The TCP window size of a client tells the server the number of bytes it is willing to receive at one time from the server; this is the client's receive window. When the window is set to 0 it means that the client won't be able to receive any more data until it process whatever data is still pending in its internal buffers. This is normal TCP stuff. The size effect of a window set to 0 on a client is that a TCP connection will still be alive for some time until the server decides he has waiting enough and kill the connection. This is what was causing my repo sync to hang with no errors.
希望这对参考这个论坛的人有所帮助。
我遇到过大型存储库的 git 克隆挂起的问题。最初速度会很高，然后急剧下降，最后挂起。这是 TCP 窗口缩放的问题。一旦禁用，它就可以正常工作。
（但奇怪的是，当我在 VMWare 中从 Linux 运行它时，没有出现任何问题。）
为当前会话禁用此功能
$ sudo sysctl -w net.ipv4.tcp_window_scaling=0
Hope this helps someone referring this forum.
I have had this issue of git clones of large repositories hanging. Initially the speed will be high and then comes down drastically and finally it hangs. It was a issue with TCP Window Scaling. Once that was disabled, it was working fine.
(But the strange part is that when I ran it from Linux in VMWare, there was no issue.)
To disable this for current session
$ sudo sysctl -w net.ipv4.tcp_window_scaling=0
有一个类似的问题回来九月，SO。
它可以与网络速度相关，或者链接到您正在使用的 Git 的确切版本。
如果是 msysgit，请更新到最新版本。
另请参阅 msysgit 问题 361
There was a similar problem back in September on SO.
It can be network speed related, or linked to the exact version of Git you are using.
If it is msysgit, please update to the latest version.
See also msysgit issue 361