Que dois-je faire lorsque le «nettoyage svn» échoue?

J'ai beaucoup de changements dans un dossier de travail, et quelque chose a foiré en essayant de faire une mise à jour.

Maintenant, lorsque j'émets un «nettoyage svn», j'obtiens:

>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 a été supprimé dans la mise à jour. Il n'existait pas auparavant dans mon dossier de travail.

Puis-je faire quelque chose pour essayer d'avancer sans avoir à extraire une nouvelle copie du référentiel?

Clarification: Merci pour les suggestions concernant le déplacement du répertoire et la réduction d'une nouvelle copie. Je sais que c'est une option, mais c'est celle que j'aimerais éviter car il y a beaucoup de changements imbriqués en profondeur dans plusieurs répertoires (cela aurait dû être une branche ...)

J'espère une façon plus agressive de faire le nettoyage, peut-être de forcer le fichier SVN à revenir dans un état connu (et j'ai essayé d'en supprimer la copie de travail ... cela n'a pas aidé).

Quand tout recommencer n'est pas une option ...

J'ai supprimé le fichier journal dans le .svnrépertoire (j'ai également supprimé le fichier incriminé .svn/props-base), fait un nettoyage et repris ma mise à jour.

Les choses ont changé avec SVN 1.7, et la solution populaire de suppression du fichier journal dans le répertoire .svn n'est pas possible avec le passage à une implémentation de copie de travail de base de données.

Voici ce que j'ai fait qui semblait fonctionner:

1. Supprimez le répertoire .svn de votre copie de travail.
2. Démarrez une nouvelle extraction dans un nouveau répertoire temporaire.
3. Annulez le paiement (nous ne voulons pas attendre que tout se déroule).
4. Exécutez un nettoyage sur ce paiement annulé.
5. Nous avons maintenant un nouveau répertoire .svn avec une base de données propre (mais pas / peu de fichiers)
6. Copiez ce fichier .svn dans votre ancien répertoire de travail corrompu.
7. Exécutez la mise à jour svn et cela devrait mettre à jour votre nouveau répertoire partiel .svn avec votre ancien répertoire de travail.

C'est un peu déroutant, du point de vue du processus. Essentiellement, ce que nous faisons est de supprimer le .svn corrompu, puis de créer un nouveau .svn pour le même chemin de paiement. Nous déplaçons ensuite ce nouveau .svn vers notre ancien répertoire de travail et le mettons à jour dans le référentiel.

Je viens de le faire dans TSVN et cela semble fonctionner correctement et ne nécessite pas de paiement complet et de téléchargement.

-Jody

Jeter un coup d'œil à

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Résumé du correctif du lien ci-dessus (Merci à Anuj Varma)

1. Installez le shell de ligne de commande sqlite (sqlite-tools-win32) depuis http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

Le SELECT devrait vous montrer votre dossier / fichier incriminé dans le cadre de la file d'attente de travail. Ce que vous devez faire est de supprimer cet élément de la file d'attente de travail.

3. sqlite3 .svn/wc.db "delete from work_queue"

C'est tout. Maintenant, vous pouvez exécuter à nouveau le nettoyage - et cela devrait fonctionner. Ou vous pouvez passer directement à la tâche que vous faisiez avant d'être invité à exécuter le nettoyage (ajout d'un nouveau fichier, etc.)

Si tout le reste échoue:

1. Vérifiez dans un nouveau dossier.
2. Copiez vos fichiers modifiés.
3. Revenez.
4. Compressez l'ancien dossier quelque part (vous ne savez jamais + la paranoïa est bonne) avant de le supprimer et d'utiliser le nouveau.

La dernière version (j'utilise la version 1.9.5) résout ce problème en ajoutant une option "Break locks" dans le menu de nettoyage. Assurez-vous simplement que cette case est cochée lors du nettoyage.

Cette réponse ne s'applique qu'aux versions antérieures à 1.7 (merci @ ŁukaszBachman) .

Subversion stocke ses informations par dossier (en .svn), donc si vous traitez simplement avec un sous-dossier, vous n'avez pas besoin de récupérer tout le référentiel - juste le dossier qui a bouché:

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 m'engager 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/propsvers .svn/prop-base.

J'ai regardé le fichier spécifique et j'ai constaté 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 qui ne diffèrent que par des majuscules. Si vous avez rencontré 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 merdiques) ne font tout simplement pas la différence entre Filenameet FILEname. Vous avez deux correctifs possibles:

1. Vérifiez sur la plate-forme avec un véritable système de fichiers (basé sur Unix), renommez le fichier et validez les modifications.
2. Lorsque vous êtes stocké sous Windows, vous pouvez renommer des fichiers dans le navigateur du référentiel Eclipse SVN qui reconnaît la différence et y renommer le fichier.
3. Vous pouvez également renommer les fichiers problématiques à distance à partir de n'importe quel client SVN en ligne de commande à l'aide de svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Exécutez la svn cleanupcommande dans un terminal (si elle échoue depuis 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é .

Équipe d' action → Échec de la mise à jour de la tête :

svn: E155004: Il y a des éléments de travail inachevés dans '/ home / user / path / to / svn-folder'; exécutez d'abord 'svn cleanup'.

Équipe d' action → Le nettoyage échoue avec la même erreur.

Solution qui a fonctionné pour moi: exécutez la commande svn cleanup dans un terminal .

La commande a réussi.

Ensuite, Team → Update dans Eclipse a de nouveau fonctionné.

Remarque: ma version SVN est 1.9.3.

Vérifiez également la réponse de Chris si svn cleanupcela ne fonctionne pas.

J'ai essayé de le faire svn cleanupvia 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 l'ai fait à svn cleanupnouveau. Cette fois, tout s'est bien passé.

J'ai eu le même problème. Pour moi, la cause était un conflit avec EasySVN et (TortoiseSVN ou simplement SVN). J'ai eu une mise à jour automatique et un commit avec EasySVN (qui ne fonctionnait pas).

Lorsque j'ai désactivé cela, je n'ai pas pu nettoyer, valider ou mettre à jour. Aucune des solutions ci-dessus n'a fonctionné, mais le redémarrage a fonctionné :)

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 obtenu une erreur sur les journaux ou quelque chose, mais je l'ai ignoré). Ensuite, dans l'explorateur, j'ai supprimé le répertoire des problèmes qui ne s'affichait plus comme 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 est la sensibilité à la casse (ce qui peut être un problème lors de la vérification sur un Mac, ainsi que sur Windows) et que vous n'avez pas la possibilité de procéder à la vérification sur un système * nix, ce qui suit devrait fonctionner. Voici le processus depuis le début:

% svn co http://[domain]/svn/mortgages mortgages

(La caisse s'ensuit… puis…)

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 la casse - Header_3_noBookmark.gifet Header_3_nobookmark.gif. Par défaut, les systèmes de fichiers Mac ne respectent pas la casse de manière à ce que SVN s'étouffe dans des situations comme celle-ci. 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, la course svn cleanupne 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.gifn'est pas le problème ici ... Il ne peut tout simplement pas passer 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

Après cela, j'ai pu retourner dans le répertoire racine du projet et exécuter svn uppour vérifier 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 un nouveau contrôle, mais avec les mêmes fichiers de travail. Pour moi, cela fonctionne toujours comme un charme.

J'ai rencontré ça trop récemment. L'astuce pour moi était après avoir sélectionné "Nettoyer", dans la boîte de dialogue des options contextuelles, cocher "Briser les verrous", puis "OK". Il a nettoyé avec succès pour moi.

Subclipse est confus par le comportement de verrouillage vraiment diabolique de Windows. Unlocker est votre ami. Cela peut trouver des fichiers verrouillés et libérer de force les verrous.

(Avant d'essayer de déplacer des dossiers et d'effectuer une nouvelle extraction.)

Supprimez le dossier dans lequel se trouvent les fichiers incriminés - oui, même le .svndossier, puis effectuez une svn cleanupsur le dossier tout en haut / parent.

J'ai fait face au même problème. Après quelques recherches sur Internet, j'ai trouvé l' article ci - dessous . Puis j'ai réalisé que j'étais connecté en tant qu'utilisateur différent de l'utilisateur que j'avais utilisé pour configurer SVN sous, un problème d'autorisation essentiellement.

Lorsque je fais face à ce problème avec TortoiseSVN (Windows), je vais sur Cygwin et j'exécute le « nettoyage svn » à partir de là; il nettoie correctement pour moi, après quoi tout fonctionne à partir de TortoiseSVN.

Les réponses ici ne m'ont pas aidé, mais avant de reprendre le projet, j'ai fermé et ouvert Eclipse (Subversive est mon client SVN) et le problème a disparu.

Cela peut ne pas s'appliquer dans toutes les situations, mais lorsque j'ai récemment rencontré ce problème, mon "correctif" consistait à mettre à niveau le package Subversion sur mon système. J'avais utilisé 1.4.quelque chose, et quand j'ai mis à niveau vers la dernière (1.6.6 dans mon cas), la caisse a fonctionné.

(J'ai essayé de le télécharger à nouveau, mais un paiement dans un répertoire propre était toujours suspendu au même endroit.)

Le verrouillage en lecture seule se produit parfois sur les lecteurs réseau avec Windows. Essayez de le déconnecter et de le reconnecter à nouveau. Ensuite, nettoyez et mettez à jour.

Après avoir parcouru la plupart des solutions citées ici, j'ai toujours eu 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 des majuscules différentes provoque un problème. Par exemple, ApproximationTest.java et Approximationtest.java ne doivent pas se trouver 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 rencontré un problème où suite à une mise à jour, SVN a montré qu'un dossier était en conflit. Étrangement, cela n'était visible que par la ligne de commande - TortoiseSVN pensait que tout allait bien.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn updateEt svn resolveont tous échoué à fixer cela.

J'ai finalement résolu le problème comme suit:

• Recherchez 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 "inachevé ..." et la somme de contrôle correspondante
• Enregistrez et réactivez l'indicateur de lecture seule
• Répétez l'opération pour le répertoire my_dir

Après cela, tout allait bien.

Notez que je n'ai eu aucun changement local, donc je ne sais pas si vous seriez à risque si vous le faisiez. Je n'ai pas utilisé la méthode de suppression / mise à jour suggérée par d'autres - je suis entré dans cet état en essayant cela dans le répertoire my_dir / sub_dir / sub_sub_dir (qui a commencé avec les mêmes symptômes) - donc je ne voulais pas risquer d'aggraver les choses encore!

Pas tout à fait sur le sujet, mais peut-être utile si quelqu'un tombe sur ce post comme moi.

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 (au moins dans Eclipse ) exécutait le nettoyage uniquement pour le dossier spécifié dans le message d'erreur et non pour l'ensemble du projet!

Je l'ai fait sudo chmod 777 -R .pour pouvoir modifier les autorisations. Sans pour autantsudo , cela ne fonctionnerait pas, me donnant la même erreur que l'exécution d'autres commandes.

Maintenant, vous pouvez faire svn updatequoi que ce soit, sans avoir à supprimer tout votre répertoire et à le recréer. Cela 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.

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.

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 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.

Tout en étant confronté à un problème similaire, la fusion manuelle dans la vue de synchronisation du référentiel a aidé à 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 plus récent sous un nom différent l'a résolu.