Que dois-je faire quand 'svn cleanup' échoue?
J'ai beaucoup de changements dans un dossier de travail, et quelque chose de foutu en essayant de faire une mise à jour.
Maintenant, quand je lance un 'nettoyage svn', je reçois:
>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control
MemPoolTests.cpp est un nouveau fichier ajouté par un autre développeur et qui a été supprimé dans la mise à jour. Cela n'existait pas dans mon dossier de travail auparavant.
Est-ce que je peux faire quelque chose pour essayer d'aller de l'avant sans avoir à extraire une nouvelle copie du référentiel?
Clarification: Merci pour vos suggestions concernant le déplacement du répertoire et la suppression d'une nouvelle copie. Je sais que c’est une option, mais c’est une solution que j’aimerais éviter car de nombreux changements ont imbriqué plusieurs répertoires en profondeur (cela aurait dû être une branche ...)
J'espère une méthode de nettoyage plus agressive, peut-être une façon de forcer le fichier que SVN a du mal à revenir dans un état connu (et j'ai essayé de supprimer la copie de travail de celle-ci ... cela n'a pas aidé.).
Quand tout recommencer n'est pas une option ...
J'ai supprimé le fichier journal dans le répertoire .svn (j'ai également supprimé le fichier incriminé dans .svn/props-base), procédé à un nettoyage et repris la mise à jour.
Les choses ont changé avec SVN 1.7 et la solution bien connue consistant à supprimer le fichier journal dans le répertoire .svn n’est plus envisageable avec le passage à une implémentation de copie de travail de base de données.
Voici ce que j'ai fait qui semblait fonctionner:
- Supprimez le répertoire .svn de votre copie de travail.
- Commencez une nouvelle extraction dans un nouveau répertoire temporaire.
- Annulez la commande (nous ne voulons pas attendre que tout soit terminé).
- Exécutez un nettoyage sur cette commande annulée.
- Nous avons maintenant un nouveau répertoire .svn avec une base de données vierge (bien que pas/peu de fichiers)
- Copiez ce fichier .svn dans votre ancien répertoire de travail corrompu.
- Exécutez svn update et votre nouveau répertoire partiel .svn devrait être mis à niveau avec votre ancien répertoire de travail.
C'est tout un peu déroutant, processus sage. Ce que nous faisons consiste essentiellement à supprimer le fichier .svn corrompu, puis à créer un nouveau fichier .svn pour le même chemin de sortie. Nous déplaçons ensuite ce nouveau fichier .svn vers notre ancien répertoire de travail et le mettons à jour dans le référentiel.
Je viens de faire ceci dans TSVN et cela semble fonctionner correctement et ne pas nécessiter une sortie complète et un téléchargement.
-Jody
Jeter un coup d'œil à
Résumé du correctif du lien ci-dessus (Merci à Anuj Varma)
Installer le shell de ligne de commande sqlite (sqlite-tools-win32) à partir de http://www.sqlite.org/download.html
sqlite3 .svn/wc.db "select * from work_queue"Le SELECT doit vous montrer votre dossier/fichier incriminé dans la file d'attente de travail. Ce que vous devez faire, c'est supprimer cet élément de la file d'attente de travail.
sqlite3 .svn/wc.db "delete from work_queue"C'est ça. Maintenant, vous pouvez lancer le nettoyage à nouveau - et cela devrait fonctionner. Ou vous pouvez passer directement à la tâche que vous étiez en train d’effectuer avant d’être invité à exécuter le nettoyage (ajout d’un nouveau fichier, etc.)
Si tout échoue:
- Vérifier dans un nouveau dossier.
- Copiez vos fichiers modifiés sur.
- Revenez dans.
- Compressez l’ancien dossier quelque part (vous ne savez jamais + la paranoïa est une bonne chose) avant de le supprimer et d’utiliser le nouveau.
La dernière version (1.9.5) permet de résoudre ce problème en ajoutant une option "Casser les verrous" dans le menu de nettoyage. Assurez-vous simplement que cette case est cochée lorsque vous effectuez un nettoyage.
Cette réponse ne concerne que les versions antérieures à 1.7 (merci @ ŁukaszBachman).
Subversion stocke ses informations par dossier (au format .svn). Ainsi, si vous traitez uniquement avec un sous-dossier, vous n'avez pas besoin d'extraire l'intégralité du référentiel, mais uniquement le dossier rempli:
cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir
Cela vous donnera une bonne copie de travail du dossier borked, mais vos modifications seront toujours sauvegardées dans borked_dir.bak. Le même principe s'applique avec Windows/TortoiseSVN.
Si vous avez des modifications dans un dossier isolé, consultez le
svn checkout -N borked_dir # Non-recursive, but deprecated
ou
svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'
$ ls -la .svn
$ rm -f .svn/lock
Ensuite
$ svn update
J'espère que ça aide
J'ai eu exactement le même problème. Je ne pouvais pas commettre et le nettoyage échouerait.
À l'aide d'un client de ligne de commande, j'ai pu voir un message d'erreur indiquant qu'il ne parvenait pas à déplacer un fichier de .svn/props vers .svn/prop-base.
J'ai regardé le fichier spécifique et trouvé qu'il était marqué en lecture seule. Après avoir supprimé l'attribut en lecture seule, j'ai pu nettoyer le dossier et valider mes modifications.
Il est possible que vous ayez un problème avec deux noms de fichiers ne différant que par des majuscules. Si vous rencontrez ce problème, la création d'un autre répertoire de copie de travail ne résout pas le problème.
Les systèmes de fichiers Windows actuels (c’est-à-dire de mauvais goût) ne font tout simplement pas la différence entre Filename et FILEname. Vous avez deux solutions possibles:
- Consultez la plate-forme avec un système de fichiers réel (basé sur Unix), renommez le fichier et validez les modifications.
- Lorsque vous êtes stocké sous Windows, vous pouvez renommer des fichiers dans le navigateur de référentiel Eclipse SVN, qui reconnaît la différence et renomme le fichier à cet emplacement.
- Vous pouvez également renommer à distance les fichiers problématiques à partir de tout client SVN en ligne de commande à l'aide de
svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename.
J'ai eu le même problème. Pour moi, la cause était un conflit avec EasySVN et (TortoiseSVN ou juste SVN). J'avais auto update et commit avec EasySVN (qui ne fonctionnait pas).
Lorsque j'ai désactivé cette option, je suis incapable de nettoyer, de valider ou de mettre à jour. Aucune des solutions ci-dessus n'a fonctionné, mais le redémarrage a fonctionné :)
Exécutez la commande svn cleanup dans un terminal (si elle échoue avec Eclipse, ce qui était mon cas):
~/path/to/svn-folder/$ svn cleanup
J'ai essayé différentes solutions expliquées ici, mais aucune n'a fonctionné .
Action Équipe → La mise à jour vers la tête échoue:
svn: E155004: Il existe des éléments de travail non terminés dans '/ home/user/path/to/svn-folder'; lancez 'svn cleanup' en premier.
Action Équipe → Le nettoyage échoue avec la même erreur.
Solution qui a fonctionné pour moi: exécuter la commande svn cleanup dans un terminal .
La commande a réussi.
Puis équipe → La mise à jour dans Eclipse a fonctionné à nouveau.
Remarque: ma version SVN est 1.9.3.
Vérifiez également réponse de Chris si svn cleanup ne fonctionne pas.
J'ai essayé de faire svn cleanup via la console et j'ai une erreur comme:
svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.
J'ai donc créé ce fichier manuellement (vide) et fait à nouveau svn cleanup. Cette fois, c'était bien fait.
J'ai couru dans ça aussi ces derniers temps. L'astuce pour moi était après avoir sélectionné "Nettoyer", dans la boîte de dialogue des options contextuelles, cochez "Verrouiller les verrous", puis "OK". Il a nettoyé avec succès pour moi.
Je viens d'avoir ce même problème sur Windows 7 64 bits. J'ai exécuté la console en tant qu'administrateur et supprimé le répertoire .svn du répertoire du problème (j'ai une erreur à propos des journaux ou quelque chose, mais je l'ai ignoré). Ensuite, dans Explorer, j'ai supprimé le répertoire du problème qui n'apparaissait plus comme étant sous contrôle de version. Ensuite, j'ai exécuté une mise à jour et les choses se sont déroulées comme prévu.
Si le problème concerne le respect de la casse (ce qui peut être un problème lors de la vérification sur un Mac, ainsi que Windows) et que vous n'avez pas l'option de vérifier sur un système * nix, ce qui suit devrait fonctionner. Voici le processus depuis le début:
% svn co http://[domain]/svn/mortgages mortgages
(Checkout ensues… alors…)
svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory
Ici, SVN essaie d'extraire deux fichiers avec des noms similaires qui ne diffèrent que par cas - Header_3_noBookmark.gif et Header_3_nobookmark.gif. Les systèmes de fichiers Mac par défaut, insensibles à la casse, provoquent l’étouffement de SVN dans de telles situations. Alors...
% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Cependant, exécuter svn cleanup ne fonctionne pas, comme nous le savons.
% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control
spacer.gif n'est pas le problème ici… Il ne peut tout simplement pas passer de l'erreur précédente au fichier suivant. J'ai donc supprimé tous les fichiers du répertoire autre que .svn et supprimé le journal SVN. Cela a rendu le nettoyage efficace, afin que je puisse extraire et renommer le fichier incriminé.
% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A foo
D Header_3_nobookmark.gif
% svn up
A spacer.gif
A Header_3_noBookmark.gif
Ensuite, j'ai pu revenir au répertoire racine du projet et exécuter svn up pour en extraire le reste.
Chaque fois que j'ai des problèmes similaires, j'utilise rsync (NB: j'utilise Linux ou Mac OS X) pour aider comme ceci:
# Go to the parent directory
cd dir_above_borked
# Rename corrupted directory
mv borked_dir borked_dir.bak
# Checkout a fresh copy
svn checkout svn://... borked_dir
# Copy the modified files to the fresh checkout
# - test rsync
# (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/
# - If all ok, run rsync for real
# (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/
De cette façon, vous avez une nouvelle caisse, mais avec les mêmes fichiers de travail. Pour moi cela fonctionne toujours comme un charme.
Subclipse est déconcerté par le comportement de verrouillage réellement diabolique de Windows. nlocker est votre ami. Cela peut trouver des fichiers verrouillés et libérer de force les verrous.
Quand je fais face à ce problème avec TortoiseSVN (Windows), je vais à Cygwin et lance le ' svn cleanup ' à partir de là; il nettoie correctement pour moi, après quoi tout fonctionne à partir de TortoiseSVN.
(Avant d'essayer de déplacer des dossiers et d'effectuer une nouvelle extraction.)
Supprimez le dossier dans lequel se trouve le ou les fichiers incriminés - oui, même le dossier .svn, puis effectuez un svn cleanup dans le dossier tout en haut/parent.
J'ai fait face au même problème. Après quelques recherches sur Internet, nous avons trouvé le sous l'article . Puis, j'ai réalisé que j'étais enregistré en tant qu'utilisateur différent de l'utilisateur que j'avais utilisé pour configurer SVN, problème de permission essentiellement.
Cela peut ne pas s'appliquer dans toutes les situations, mais lorsque j'ai récemment rencontré ce problème, mon "correctif" consistait à mettre à jour le paquet Subversion sur mon système. J'avais utilisé une version 1.4.quelque chose, et lorsque j'ai mis à niveau vers la dernière version (1.6.6 dans mon cas), le paiement a fonctionné.
(J'ai essayé de le télécharger à nouveau, mais une extraction vers un répertoire vierge a toujours été suspendue au même endroit.)
Je viens de supprimer le fichier svn-xxxxxxxx du dossier ~\.svn\tmp, où xxxxxxxx est un nombre.
Il y a de très bonnes suggestions dans la réponse précédente, mais si vous rencontrez un problème avec TortoiseSVN sous Windows (un bon produit, mais ...), retournez toujours à la ligne de commande et faites d'abord un simple "nettoyage de svn".
Dans de nombreuses circonstances, le client Windows n'exécutera pas la commande de nettoyage, mais le nettoyage fonctionne correctement à l'aide de l'utilitaire de ligne de commande SVN.
Non non Non! Si vous utilisez SVN 1.7 ou supérieur, la commande de nettoyage devrait faire l'affaire!
J'ai également fait quelques expériences et découvert que la solution (du moins dans Eclipse ) exécutait le nettoyage uniquement pour le dossier spécifié dans le message d'erreur et non pour le projet entier!
J'ai résolu ce problème en copiant le répertoire .svn d'un collègue dans le mien, puis en mettant à jour ma copie de travail. C'était une solution agréable, rapide et propre.
J'ai rencontré un problème où, après une mise à jour, SVN a montré qu'un dossier était en conflit. Étrangement, cela n'était visible que via la ligne de commande - TortoiseSVN pensait que tout allait bien.
#>svn st
! my_dir
! my_dir\sub_dir
svn cleanup, svn revert, svn update et svn resolve n'ont pas réussi à résoudre ce problème.
J'ai finalement résolu le problème comme suit:
- Cherchez dans le répertoire .svn "sub_dir"
- Utilisez RC -> Propriétés pour décocher le drapeau 'lecture seule' sur le fichier d'entrées
- Ouvrez le fichier d'entrées et supprimez la ligne "unfinished ..." et la somme de contrôle correspondante
- Enregistrer et réactiver l'indicateur en lecture seule
- Répéter pour le répertoire my_dir
Ensuite, tout allait bien.
Notez que je n’ai eu aucun changement local, donc je ne sais pas si vous courriez un risque si vous l’aviez fait. Je n'ai pas utilisé la méthode de suppression/mise à jour suggérée par d'autres personnes - je suis entré dans cet état en essayant cela dans le répertoire mon_dir/sous_dir/sous_sub_dir (qui a commencé avec les mêmes symptômes) - je ne voulais donc pas risquer d'empirer les choses encore!
Pas tout à fait sur le sujet, mais peut-être utile si quelqu'un rencontre ce message comme je l'ai fait.
Les réponses ne m'ont pas aidé, mais avant de relancer le projet, j'ai fermé et ouvert Eclipse (Subversive est mon client SVN) et le problème a disparu.
Après avoir passé en revue la plupart des solutions citées ici, j'entendais toujours l'erreur.
Le problème était OS X insensible à la casse . L'extraction d'un répertoire contenant deux fichiers portant le même nom, mais une casse différente, pose un problème. Par exemple, ApproximationTest.Java et Approximationtest.Java ne doivent pas figurer dans le même répertoire. Dès que nous nous débarrassons de l'un des fichiers, le problème disparaît.
J'ai fait Sudo chmod 777 -R . pour pouvoir changer les permissions. Sans Sudo, cela ne fonctionnerait pas, me donnant la même erreur que d'exécuter d'autres commandes.
Maintenant, vous pouvez faire svn update ou quoi que ce soit, sans avoir à supprimer tout votre répertoire et à le recréer. Ceci est particulièrement utile car votre IDE ou votre éditeur de texte peut déjà avoir certains onglets ouverts ou avoir des problèmes de synchronisation. Vous n'avez pas besoin de supprimer et de remplacer votre répertoire de travail avec cette méthode.
Le verrouillage en lecture seule se produit parfois sur les lecteurs réseau avec Windows. Essayez de vous déconnecter et de le reconnecter. Ensuite, nettoyez et mettez à jour.
Face à un problème similaire, la fusion manuelle dans la vue de synchronisation du référentiel a permis de résoudre le problème.
Un nom de fichier était en conflit avec un autre et il mentionnait clairement le problème. Renommer le fichier le plus récent en un autre nom l'a résolu.