Nous utilisons VisualSvn Server ici au travail et tout fonctionne bien, nous avons plus de 50 référentiels. J'ai essayé aujourd'hui de mettre dans un référentiel un site Web, mais il ne cesse de s'écraser sur un seul fichier unique que j'ai isolé.
Event Type: Error Event Source: VisualSVN Server 2.5 Event Category: Apache Event ID: 1001 Date: 1/23/2012 Time: 9:37:10 AM User: ACTIVIS-991RBEL\Mathieu Dumoulin Computer: DELL-PE2900-01 Description: Could not get next bucket brigade [500, #0] [client 192.168.0.64]
8 Réponses :
Ceci ressemble à ce bogue:
Il s'est avéré être dans le filtre d'entrée (avoir à voir avec un codage chund); Si le téléchargement se termine avant l'attente, le téléchargement échoue car le serveur s'attend à plus de données, même si la fin du flux avait été envoyée.
OK, alors le bogue est dans le filtre d'entrée.
J'étais sous l'impression (erronée) que ce bogue n'apparaît que si
longueur de contenu est donné. Mais il apparaît également avec un codage décédé si le premier morceau est transféré complètement et le corps est tronqué plus tard.Je m'attendrais à ce que deux choses puissent vous aider:
une mise à jour de VisualSvn pour résoudre ce problème pour vous; Le bogue lié aura une solution pour Apache dans R792409
*) noyau: retour APR_EOF si le corps de la demande est plus court que la longueur annoncée par le client. PR 33098 [Stefan Fritsch]
- Mon manque d'expérience (récente) avec VisualSvn me fait douter s'il y a eu lieu avec le fichier particulier (il peut contenir des caractères offensants; cela étant Windows, je pense que ASCII 26 (^ z) pourrait être interprété comme eof . Voir si votre fichier contient des caractères «drôles» ou vous pouvez le mettre en mode binaire (soit pour le fichier unique, ou pour l'ensemble du serveur).
Interresting, pourrait être la solution mais je ne sais pas quoi faire pour résoudre ce problème (R792409) Parce que je n'utilise que l'installateur et j'ai la dernière version installée, donc à moins qu'ils ne publient une version corrigée que je ne puisse pas y remédier. Pour le caractère invalide, je me demande, ne le ferait-il pas sur tous les serveurs? J'ai essayé de commettre les données à un autre serveur sur une machine UNIX et que cela ne l'a pas fait ... Strange non?
Et si le transligérateur s'est écrasé à cause de personnages «drôles» de l'URL, tous les fichiers de caractères «drôles» et non seulement un? J'ai vu quelques fichiers passés par des és et ès (les personnes téléchargent des fichiers avec des accents ... et notre CMS ne se soucie pas de les supprimer sur le téléchargement) et tous passer, d'une fois dans un tandis que.
@ Fredy31: Qui a dit quoi que ce soit sur les URL? Je parlais du contenu du fichier
@Mathieuudumoulin: C'est malheureux. Avez-vous essayé la pré-version ( visuelsvn.com/visualsvn/download/pre-release )? Je ne vois pas ce qui était en amont qui était basé cependant. Aussi, ne le ferait-il pas sur tous les serveurs - peut-être pas, car il existe des différences de plate-forme sur la manipulation de fichier texte (selon laquelle les API sont utilisées avec quels modes)
En ce moment, je considérerais le que je vais résoudre le problème par «Dumping» Visual Svn Approche. +1
OMG, j'ai passé 2 jours à migrer de Visual Svn vers un tout nouveau serveur basé à Ubuntu et le problème persiste ...
Après tout, nous avons découvert que la modification de la modification du fichier et de l'engagement des œuvres, pourrait toujours être liée au pare-feu car c'est le seul dernier élément de la manière. Mais changer les œuvres de signature du fichier ...
Problème vraiment vraiment très étrange ...
J'ai résolu ce problème en désactivant Kaspersky Internet Security sur le PC client en commits, mais je ne le résout pas si cela résoudra également la question dans votre cas.
J'ai eu un problème similaire et je confirme que Kaspersky Internet Security 2012 pour le moment de la validation résout le problème dans mon cas. Si quelqu'un est également confronté à un tel problème, vous devez vérifier si le logiciel antivirus / pare-feu ne bloque pas la transmission SVN.
J'ai connu le même problème. Cela n'arrive jamais avec une connexion réseau locale. Lorsque je m'engage dans un référentiel SVN sur un autre côté de la planète via VPN, cela se produit assez souvent.
Désactiver Kaspersky Internet Security 2012 aide, mais pas toujours.
De plus, je fais souvent mon travail et je mets souvent à partir d'une machine virtuelle VirtualBox. Parfois, même le redémarrage simple du VM aide.
Une autre solution consiste à empêcher la fragmentation IP. Vous pouvez vérifier que vos paquets sont fragmentés à l'aide de la commande ping: S'il y a une fragmentation de paquets, vous pouvez réduire votre taille MTU. Ce Link fournit une bonne description comment changer la taille du MTU.
Malheureusement, toutes les solutions mentionnées ci-dessus ne sont pas 100% fiables. Cette erreur ressemble à un mystère pour moi aussi. Je ne peux pas comprendre pourquoi Svn est si sensible à ces choses. ping host_name -f
Programme anti-virus (Kaspersky) portait la plupart des problèmes de notre réseau de bureau local. La désactivation du programme anti-virus a résolu le problème (dans la plupart des cas).
J'ai souffert de ce problème au cours des derniers jours et j'ai enfin réussi à le réparer.
On dirait que les guides suivants manquaient, ou ma propre ignorance, je n'avais pas fait le bon chipel sur mon référentiel. Et il semble que toutes les données soient traitées comme du texte, ce qui provoque l'extrémité des caractères de fichier dans des données binaires pour provoquer l'erreur de brigade de godet dans Apache. P>
Une fois que j'avais fait correctement le chipel avec les éléments suivants: P >
sudo chown -R www-data:www-data /home/svnrepo
Je pense avoir trouvé une source possible de cette erreur (au moins dans mon cas):
Cela est dû à une sortie d'espace disque sur le disque / la partition où votre repo est situé sur.
mon cas:
Erreur rencontrée
Essayé de chercher si commit a réussi via VisualSvn
Repo était toujours en état avant de s'engager
L'espace disque coïntement vérifié, était zéro
Supprimer un fichier aléatoire pour libérer la mémoire (CA 10MB)
Commettre fonctionne maintenant
TL; DR: libérer une certaine mémoire sur le disque Votre référentiel est stocké, pas assez de memeory est probablement la culprint de ce bug
Il peut y avoir plus d'informations dans les journaux du serveur. En supposant que vous exécutez Apache, jetez un coup d'œil au fichier Error_Log d'Apache sur le serveur.
J'ai ajouté des informations à la question, j'ai regardé autour de ce que cela "ne pouvait pas obtenir la prochaine brigade de seau", rien à voir avec le pare-feu car les communications internes ne sont pas lafectionnées par pare-feu. J'ai essayé de désactiver l'antivirus pour les dossiers de référentiel au cas où quelque chose pourrait être interprété comme un virus ... Le problème se produit de plus en plus sur de nombreux autres référentiels ... est-il un moyen de vérifier l'intégrité des référentiels SVN?
@Mathieuudumoulin -
SVN Vérifier + (si nécessaire)svn récupérer . Et n'oubliez pas deDump avant de récupérerJe vais résoudre le problème par "Dumping" Visual Svn, j'attends simplement que mon patron commande ce nouveau serveur et que je construirai la lampe avec Linux SVN à la place. Jamais cela auparavant alors je soupçonne que c'est quelque chose à voir avec un outil externe tel qu'un pare-feu ou un anti-virus ...
OH et BTW, ce problème s'est étendu à 6/7 autres référentiels et à une douzaine de fichiers. C'est donc vraiment quelque chose à voir avec la signature du fichier ... c'est pourquoi je pousse cela à un serveur de solution non viral, car je Pensez que c'est l'anti-virus qui fait des choses étranges, même s'il n'y a pas de virus dans notre code ...
Question vraiment stupide - avez-vous vérifié que vous avez beaucoup d'espace de fichier sur les serveurs? Cela ressemble à un système de fichiers à court d'espace, une erreur d'autorisations ou anti-virus étant une mauvaise erreur plutôt qu'une erreur SVN.
Eh bien, si c'était une erreur d'espace, nous n'aurions pas pu commettre 7-8 concerts de fichiers clients téléchargés au cours de la dernière journée, donc non, ce n'est pas si ...;)
Si vous utilisez VisualSVN, assurez-vous que VisualSVN commence en tant que système local plutôt qu'à l'utilisateur du réseau.