Dossiers obstrués dans Subversion

Que diable signifie «obstrué» lorsque vous essayez de vous enregistrer dans Subversion? Je vois deux dossiers en rouge avec le statut de texte «obstrué». Je ne vois ce que cela signifie nulle part dans la documentation.

Lorsque j'essaye la cleanupcommande, j'obtiens "le nom du dossier n'est pas un répertoire de travail". C'est un dossier que je viens de créer dans VS, et quand j'essaye de l'ajouter à Subversion, cela me donne cette erreur. Tous les autres dossiers vont bien.

cela se produit lorsque vous avez supprimé ou déplacé les sous-répertoires .svn (sans passer par les commandes SVN), donc SVN a une vue corrompue de la copie de travail.

Essayez d'abord un nettoyage, et si cela ne résout pas le problème, rétablissez (ou mettez à jour) le répertoire pour restaurer les dossiers du sous-répertoire .svn.

Sans savoir ce qui cause cela, la solution peut être d'exporter la copie de travail (l'intégralité de l'extraction que vous avez localement) vers un autre endroit.

Si vous utilisez tortoisesvn, vous avez la possibilité "d'exporter les fichiers non versionnés", mais je pense que si vous le faites à partir de la ligne de commande, il n'exporte que les fichiers versionnés, donc vous pourriez avoir un peu de tâche laborieuse à copier manuellement les fichiers non versionnés .

Une fois terminé, extrayez une copie de travail propre, puis déposez la sauvegarde exportée que vous avez par-dessus. Il est très important que la sauvegarde ne contienne aucun dossier .svn.

J'ai déjà vu ces erreurs lorsque des personnes ont extrait des copies de travail dans d'autres copies de travail ou tout autre élément qui corrompt les entrées .svn.

J'ai eu le même problème et l'a corrigé comme ceci:

• renommé le répertoire obstrué
• créé le répertoire avec son nom d'origine dans SVN (par exemple svn mkdir)
• mis à jour le dossier parent, de sorte que le répertoire nouvellement créé apparaisse dans ma copie de travail
• copié les fichiers du répertoire obstrué vers le répertoire nouvellement créé et les a validés

Si vous êtes sur un système * nix, assurez-vous que vous n'avez pas créé de fichier, ajoutez-le à SVN, puis supprimez-le en le remplaçant par un dossier du même nom. N'aide pas OP, mais j'espère que cela épargnera beaucoup de stress à quelqu'un.

Cela signifie que, pour une raison quelconque, un conflit est survenu pendant l'opération. Vérifiez s'il existe un fichier ou un dossier non versionné existant avec le même nom qu'un versionné.

(Paraphrasé à partir du fichier d'aide du client Tortoise SVN)

Rien n'a fonctionné pour moi, j'ai donc fait ce qui suit:

• exporté avec les fichiers non versionnés dans un nouvel emplacement
• renommé le dossier existant
• déplacé le dossier de l'emplacement d'exportation dans le projet
• renommé le nouveau dossier
• ajouter, valider
• supprimé l'ancien dossier renommé
• renommé le nouveau dossier
• commettre

Il existe différentes variantes de scénario qui peuvent provoquer cette situation. Voici un exemple:

J'ai fini avec le! marque sur un répertoire qui a été renommé de www à www_a sans utiliser la commande 'svn rename':

1. Renommez le répertoire actuel qui porte le nom d'origine, par exemple en www_b
2. Renommez www_a en www
3. Assurez-vous de faire 'svn update' ou 'svn revert' dans le répertoire www
4. Supprimez le répertoire www mis à jour sans utiliser 'svn delete'
5. Allez dans le répertoire parent et lancez 'svn update'
6. Cela restaurera le répertoire www d'origine
7. Cette fois, utilisez 'svn rename' pour renommer www en www_a
8. Renommez www_b en www
9. Utilisez 'svn add' pour l'ajouter dans le référentiel

Vous devriez obtenir un répertoire de travail svn correct à ce stade. Et apprenez une ou deux choses sur la façon de résoudre la confusion du répertoire svn.

Face à ce problème sur une machine Windows.

J'avais vérifié le répertoire avant de retirer tout le projet auquel il appartenait. Cela a causé le problème de «l'obstruction» pour moi.

J'ai simplement supprimé ce dossier et exécuté une mise à jour à partir de la racine (de ce dossier). Cela a bien fonctionné.

Les commandes comme le nettoyage, etc. ne fonctionnaient pas pour moi.

Un mot d'avertissement:

1. Ceci est coûteux si le dossier est volumineux.
2. Cela vous fera perdre toutes vos modifications s'il y en a.

Bonne chance.

J'ai également vu cela sur Windows lorsque j'ai créé un lien symbolique vers un répertoire de référentiel; dans ce cas, la racine du référentiel est considérée comme "obstruée". Cela ne semble cependant pas avoir d'effet.

Étapes à suivre pour reproduire:

1. Commander votre repo

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Vérifiez que votre répertoire est OK

   cd plugin_dir
   svn st -u
   

   La sortie doit être

   Status against revision: 1234
   

3. Créez le lien symbolique (qui montre le problème)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   La sortie sera

   ~           1234  .
   Status against revision: 1234
   

J'ai rencontré ce problème en collant un dossier avec des sous-répertoires dans ma copie de travail à l'aide de mon client FTP - je savais que j'avais merdé dès que j'ai appuyé sur le bouton de transfert ... les dangers de travailler trop tard.

J'ai essayé toutes les suggestions ci-dessus et d'autres trouvées en ligne en vain. Chaque option a produit l'erreur que mon répertoire était verrouillé et l'opération n'a pas pu être effectuée.

Je suis entré dans ma copie Time Machine, j'ai restauré le répertoire et j'étais prêt à partir. J'ai nettoyé la copie de travail par mesure de précaution, mis à jour mes fichiers correctement et j'ai repris mes activités.

Nous avons souvent plusieurs branches en mouvement en même temps, afin de m'éviter de changer ou de déconner avec la configuration IIS, je vérifie chaque branche dans un dossier séparé. J'utilise ensuite la liaison de répertoire pour connecter ces dossiers au chemin principal configuré dans IIS.

Donc, pour moi, le répertoire lié a toujours une exclamation jaune et est marqué comme obstrué. Je pense que c'est parce qu'il a été techniquement créé / déplacé en dehors de SVN.

J'obtiens ce statut «obstrué» sur les répertoires lorsque je mets à jour un CMS (WordPress ou Drupal) via l'interface Web - l'application ne sait pas que son code est en fait une copie de travail de subversion, donc lors de la mise à jour d'un plugin, elle supprime ce plugin répertoire (y compris le .svnrépertoire) et tombe dans un nouveau répertoire à partir de la nouvelle version du plugin.

Pour récupérer ce .svnrépertoire, depuis le répertoire contenant le répertoire obstrué. Je passe à la caisse avec --force. Par exemple, si plugin_direst marqué "~", à partir de son répertoire parent, je lance:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Tous les fichiers déjà présents sont laissés seuls et marqués "E" sur la sortie de la commande d'extraction (marqué comme "M" lorsque je cours svn status).

Je dois parfois revenir en arrière et ajouter des fichiers qui étaient nouveaux avec la mise à jour; ou supprimez les fichiers qui devraient être supprimés dans le cadre de la mise à jour, car ils sont réapparus lorsque j'ai effectué le paiement. Je crois que ceux-ci sont marqués comme "A" à la caisse, mais un suivant svn statusne les mentionnera pas.

J'ai rencontré cela dans Eclipse où certains fichiers étaient marqués d'un point d'exclamation rouge. Le problème était un dossier .svn errant dans le répertoire source. J'ai supprimé le dossier .svn, actualisé l'éclipse et j'ai pu archiver les fichiers.

Cela peut également se produire lorsque vous mettez à niveau votre subversion vers une version que XCode ne prend pas en charge.

Voici le moyen le plus simple (et le plus sûr) que j'ai trouvé pour résoudre ce problème:

1. Renommez temporairement le fichier ou le répertoire incriminé (ou un répertoire parent) qui est obstrué (par exemple, ajoutez ".backup").
2. Supprimez tous les .svnrépertoires à l'intérieur du répertoire renommé (le cas échéant).
3. svn revert l'objet renommé (et maintenant manquant) de l'étape 1.
4. svn delete l'objet rétabli.
5. Renommez la sauvegarde de l'étape 1 à son nom d'origine.
6. Ajoutez et réintégrez l'objet renommé dans svn en tant que nouvel objet.

Cela m'est venu à l'esprit lorsque j'ai remplacé un fichier par un dossier portant exactement le même nom. Résolu en supprimant l'ancien fichier, validez, puis ajoutez le nouveau. Un peu hacky, mais a fonctionné pour moi :)

J'ai supprimé .svn dans les répertoires obstrués et je l'ai mis à jour de l'extérieur. Ensuite, la commande svn extérieure reconnaîtra ces fichiers.