tortoisesvn - La demande de compte rendu d'erreur a échoué le ../../../!svn/vcc/default
Les utilisateurs essayant d'extraire des fichiers d'un référentiel Subversion 1.4.x particulier avec Apache 2.2 sous Windows 2003 ont soudainement commencé à recevoir un message d'erreur dans leurs fenêtres de journal lors de leur commande avec TortoiseSVN 1.4:
Error REPORT request failed on '/[path_to_repo]/!svn/vcc/default'
Error REPORT of '/[path_to_repo]/!svn/vcc/default': 200 OK (http://[server_name])
Cela a commencé après un crash du disque dur sur le serveur et la restauration ultérieure d'environ 10 référentiels Subversion. Un seul référentiel rencontre ce problème après une tentative de rapprochement des répertoires de travail. Le propriétaire du référentiel réconcilie son répertoire de travail avec le référentiel en modifiant/supprimant les répertoires cachés .svn (bien que cela ne soit pas conseillé).
Je ne trouve rien sur Internet qui représente ma situation. Le serveur restauré est identique à l'original et aucun autre référentiel sur ce serveur ne génère d'erreurs. Des idées sur 1) en quoi consiste cette erreur et 2) comment la réparer?
L'incidence de l'erreur SVN {REPORT of '/ svn/xxxx /! Svn/vcc/default': 200 OK} lors d'une tentative d'extraction ou de mise à jour dans SVN a finalement été résolue sur notre site en redémarrant le serveur SVN.
Réponse tardive mais j'espère que ça vous sera utile.
J'ai eu ce problème et cela n'a rien à voir avec le serveur mais a été causé par une opération étrange du côté client (renommer un répertoire et ne pas engager la création de la destination pour autant que je m'en souvienne).
J'essaie d'abord de trouver le répertoire défectueux en utilisant le liner suivant:
for fic in $(find . -type d | grep -v -e './target' -e '/.svn'); do echo $fic; svn up -N $fic; done
Le -Nswitch empêche svn de récursir svn dans des sous-répertoires, ce qui aide à identifier le répertoire défectueux dans mon cas, ./src/main/resources/META-INF. Comme je n'avais rien non engagé dans ce répertoire, je l'ai supprimé.
svn status m'indique que le répertoire était manquant et un simple svn update l'a ramené à la vie et a corrigé mon problème.
J'ai rencontré ce problème sur SubClipse & Subversive sur Eclipse et TurtoiseSVN. J'ai supprimé le répertoire du référentiel local, ce qui n'a PAS résolu le problème. Enfin, nous avons augmenté le délai d'attente HTTP sur le serveur Apache, ce qui a résolu le problème.
J'ai eu ce problème également.
J'ai découvert en utilisant TortoiseSVN que lorsque je mettais à jour des parties du référentiel, la plupart fonctionnaient, mais un dossier renvoyait l'erreur. Je suis allé à l'intérieur et mis à jour des portions et j'ai réalisé que un fichier était corrompu ou quelque chose. C'était un fichier csv. Sa somme de contrôle était fausse et l'encodage était bizarre. J'ai supprimé le fichier et l'ai remplacé par une version fonctionnelle du fichier. L'erreur a disparu.
J'obtenais l'erreur suivante lors de la vérification de mon dépôt:
svn: E175002: REPORT of '/!svn/vcc/default': 200 OK
Je sers le repo en tant que proxy Apache via nginx. En regardant le journal des erreurs nginx, je vois ce qui suit:
[crit] 25839#0: *37 open() "/var/lib/nginx/tmp/proxy/1/00/0000000001" failed (13: Permission denied) while reading upstream, client: xx.xx.xx.xxx, server: my.domain.com, request: "REPORT /!svn/vcc/default HTTP/1.1", upstream: "http://127.0.0.1:8080/!svn/vcc/default"...
Pour résoudre finalement le problème, je devais changer le propriétaire/groupe de mon dossier/var/lib/nginx et de mon dossier/var/lib/nginx/tmp afin de correspondre à ce que/var/lib/nginx/tmp/proxy utilisait. Dans mon cas, j'ai un utilisateur spécial "www" utilisé par Apache et nginx. Le groupe était "root".
Nous avons eu le même problème sur un dossier spécifique de notre projet. Ce qui suit a résolu le problème:
- sauvegarder le dossier sur un emplacement externe
- En utilisant repo-browser, supprimez le dossier du svn.
- Supprimé le dossier physique de l'ordinateur.
- émettre une mise à jour SVN.
- Cela pourrait provoquer un conflit d'arbre. - marquer le conflit comme étant résolu.
- Assurez-vous que le dossier n'existe pas sur l'ordinateur.
- restaurer le dossier à partir de la sauvegarde, l'ajouter et le valider.
Avez-vous changé quelque chose dans votre répertoire (caché) .svn?
Vous pouvez récupérer la copie originale du répertoire .svn ou le supprimer. SVN ne peut pas gérer cette "différence" entre les versions. Il pense que c'est une autre version au lieu de la même chose avec un répertoire .svn différent.
Contexte: Nous utilisons des serveurs sur lesquels SVN est installé par différents utilisateurs.
J'ai donc essayé l'option de réinstaller le SVN chez l'utilisateur qui utilise actuellement et cela a résolu les problèmes. (Windows. Aussi lors de la première installation, vous pouvez installer avec l'option pour que tous les utilisateurs l'utilisent).
Nous ne rencontrons plus l'erreur après avoir essayé de supprimer l'authentification enregistrée, supprimons tout le contenu de ce dossier AppData\Roaming\Subversion\auth\, puis nous reconnectons
Une nouvelle commande résolue le problème pour moi. Dans mon cas, le problème concernait une structure de répertoire qui avait été attribuée par erreur au référentiel (par exemple, "existingfolder\C:\inputpub\etc ..."), ce qui provoquait des problèmes étranges après une tentative de suppression du répertoire et de validation.
J'ai juste essayé plusieurs fois de plus, par frustration plus que toute autre chose, et finalement cela a fonctionné. Supposons que quelque chose de mauvais réseau ait causé cela.