2 votes

svn diff renvoie E175009 après ~25 minutes

J'essaie de mapper un repo SVN dans Fisheye/Crucible pour l'utiliser avec la fonction de revue de code. Je rencontre des problèmes avec l'une des commandes que Fisheye exécute, mais la source du problème semble provenir du serveur SVN. J'utilise le serveur VisualSVN 3.6.1, 64 bits.

svn diff --summarize -r 6427:6428 http://file2/svn/REPO/@6428

J'ai testé la même commande localement sur le serveur SVN, mais après environ 25 minutes, le flux de texte a été interrompu par le message suivant

svn: E175009: The XML response contains invalid XML
svn: E130003: Malformed XML: no element found

Les exemples de cette erreur que j'ai trouvés semblent indiquer que l'URL n'a pas été correctement saisie dans la commande, mais cela ne semble pas s'appliquer à mon cas, car environ 110 Mo de données sont descendus initialement.

La surveillance de l'observateur d'événements pendant l'exécution de la commande génère 3 erreurs, mais n'entraîne pas l'arrêt de l'exécution de la commande. Les réexécutions ultérieures donnent lieu aux mêmes 3 erreurs à chaque fois.

Provider encountered an error while streaming a REPORT response.  [500, #0]
A failure occurred while driving the update report editor  [500, #106]
Unknown error  [500, #106]

SVN Verify contre le repo ne rapporte aucun problème.

Comme solution de contournement, je peux configurer Fisheye pour qu'il commence à indexer après la révision problématique, mais cela a pour conséquence que les fichiers modifiés avant cette révision ne sont pas pris en compte dans les données de diff dans une révision, ce n'est donc pas idéal.

Mise à jour 1 Les révisions en question semblent concerner une refonte de la mise en page du dépôt, et j'ai lu que cela pouvait causer des problèmes lors de l'utilisation d'un outil tiers. J'ai également noté qu'il y avait un bogue dans le SVN avant la version 1.9.5 qui permettait l'utilisation de caractères invalides dans le XML, donc j'essaie de rétrograder la version pour voir si cela peut aider.

Mise à jour 2 Ces problèmes semblent être causés par une branche particulière qui a été créée lors de la refonte de la disposition des dépôts mentionnée ci-dessus. D'autres recherches suggèrent que je pourrais utiliser svndumpfilter pour supprimer les éléments indésirables. Je n'ai rien trouvé concernant la manière de supprimer une branche, mais seulement des fichiers particuliers. J'ai également essayé d'exporter et d'importer le dépôt vers une nouvelle installation, mais cela n'a pas résolu le problème.

En général, l'administration de SVN a été assez facile, mais je ne sais pas comment résoudre ce problème. Toute suggestion serait grandement appréciée. Merci.

0voto

Nick Points 1551

J'ai pu éviter cette erreur en configurant l'accès au référentiel par le protocole svn://. Bien que ce protocole ne soit pas directement supporté par VisualSVN, le svnserve.exe nécessaire était présent et a été configuré comme un nouveau service pointant vers une copie du dépôt.

sc create svncustom binpath= "\"C:\Program Files (x86)\VisualSVN Server\bin\svnserve.exe\" --service -r F:\RepositoriesCopy" displayname= "Subversion Workaround Server" depend= Tcpip start= auto

Cela ne semble pas être une solution sûre, mais cela supprime l'erreur que je rencontrais, à savoir un blocage dur.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X