Repo sync se bloque

Question

J'essayais d'obtenir les sources pour la version Android 1.6, mais l'opération de synchronisation repo reste suspendue.

Je suis coller la dernière partie du message que je reçois sur le terminal ici:

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 

Il se bloque juste là ... aucun message d'erreur ou aything de ce genre.

Est-ce que quelqu'un a rencontré un problème similaire?

Answer 1

Il y avait un problème similaire back in September on SO.

Cela peut être lié à la vitesse du réseau, ou lié à la version exacte de Git que vous utilisez.
S'il s'agit de msysgit, veuillez mettre à jour vers la dernière version.
Voir aussi msysgit issue 361

Answer 2

Je me demande si vous utilisez VMWare pour exécuter Linux. J'ai rencontré le même problème que vous jusqu'à ce que j'ai trouvé ce qui le provoquait: la taille de la fenêtre tcp de notre côté étant définie sur 0 (plein). Je cours Ubuntu 10.04 sur VMWare sur Windows 7 64 bits en tant qu'hôte. Pour résoudre ce problème, assurez-vous de donner beaucoup de RAM à Ubuntu sur VMware pour éliminer tout problème de mémoire. J'avais le mien fixé à 512 Mo et l'augmenter à 1,5 M pour de meilleures performances. Ensuite, le paramètre le plus important (et celui qui a fait l'affaire en fait): assurez-vous de définir la carte réseau sur VMWare en mode ponté. Si vous utilisez NAT par exemple, le service NAT va s'étouffer et gâcher la taille de la fenêtre pour vous.

Cause: La taille de la fenêtre TCP d'un client indique au serveur le nombre d'octets qu'il souhaite recevoir à la fois du serveur; c'est la fenêtre de réception du client. Lorsque la fenêtre est définie sur 0, cela signifie que le client ne pourra plus recevoir de données tant qu'il n'aura pas traité toutes les données en attente dans ses tampons internes. C'est un truc TCP normal. L'effet de taille d'une fenêtre définie sur 0 sur un client est qu'une connexion TCP sera encore active pendant un certain temps jusqu'à ce que le serveur décide qu'il a suffisamment attendu et tue la connexion. C'est ce qui causait ma synchro de repo à accrocher sans erreurs.

Answer 3

J'espère que cela aidera quelqu'un à référencer ce forum.

J'ai eu ce problème de clones git de grands dépôts suspendus. Au départ, la vitesse sera élevée, puis descendra radicalement et finalement elle se bloque. C'était un problème avec TCP Window Scaling. Une fois que c'était désactivé, ça fonctionnait bien.

(Mais la plus étrange est que quand je l'ai couru de Linux dans VMWare, il n'y avait pas de problème.)

Pour désactiver cette session pour $ sudo sysctl -w net.ipv4.tcp_window_scaling = 0