Comment réparer "la zone d'administration contenant la copie de travail est manquante" dans SVN?

184

J'ai supprimé manuellement un répertoire que je viens d'ajouter, hors ligne, dans mon référentiel. Je ne peux pas restaurer le répertoire.

Toute tentative de mise à jour ou de validation échouera avec:

"blabla/.svn" containing working copy admin area is missing.

Je comprends pourquoi, mais y a-t-il de toute façon pour résoudre ce problème.

Je ne veux pas vérifier l'intégralité du dépôt et y ajouter mes modifications manuellement, cela prendrait des heures.

e-satis
la source

Réponses:

148

Selon ceci: http://www.devcha.com/2008/03/svn-directory-svn-containing-working.html

Extrayez le dossier «blabla» à un autre emplacement, puis copiez son dossier .svn dans le «blabla» d'origine.

marque
la source
62
J'ai tellement SVN. Le fait de jeter des .svnsous-répertoires partout a dû être la pire idée de l'histoire du contrôle de version.
Johannes Fahrenkrug
9
Mes amis, consultez les suggestions ci-dessous de Rob, c'est beaucoup plus simple que la solution actuelle.
Mohammad Arif
Mohammed, merci pour la mise en garde. Cela a fonctionné pour moi. J'essayais de faire en sorte que SVN ignore un répertoire de journal et la suppression de .svn m'a amené à ce problème. La solution de Rob l'a résolu.
Asmor
Johannes, je ne suis pas non plus un partisan de SVN mais l'avantage des répertoires .svn est que vous pouvez extraire les sous-répertoires d'un référentiel et maintenir le contrôle de version.
Joseph Persie
@MohammadArif, Il y a deux "Robs" maintenant
Charles Clayton
123

fwiw, j'ai eu une situation similaire et j'ai utilisé svn --force delete __dir__ . Cela a résolu le problème pour moi. Ensuite, j'ai continué à travailler normalement avec ma copie de travail.

Matt Setter
la source
2
Cela a fonctionné pour moi aussi. Les mises à jour et les nettoyages ont échoué car le répertoire n'a jamais été dans le référentiel, mais la copie de travail était sûre qu'il était sous contrôle de révision. Je me demande si j'ai ajouté le répertoire, puis je l'ai supprimé avant de le valider?
Magnus
1
C'est très bien. J'avais ajouté un répertoire, supprimé le .svn mais jamais engagé. Cela a totalement fait l'affaire
Eric
8
Je vous remercie; cette réponse m'a fait gagner beaucoup de temps. svn cleanupa ensuite svn --force delete <directory-that-doesn't-exist-but-should>travaillé pour moi.
mpontillo
J'ai travaillé sur le deuxième essai, j'ai d'abord essayé sans --force, qui laissait en quelque sorte un fichier de verrouillage dans .svn du parent que je devais supprimer manuellement. La deuxième fois avec --force a résolu le problème.
Jörn Horstmann
3
Hm, cette commande me donne simplement la même erreur de "copie de travail".
Oscar
72

Ce que j'ai fait pour résoudre ce problème, c'était de supprimer la copie locale du dossier en question, puis de faire un svn updatedu parent directement après.

Corrigé tout de suite.

Maurizio
la source
3
Je ne peux pas croire ... J'ai tout essayé ... et c'était aussi simple que ça !!! Cela a parfaitement fonctionné, merci beaucoup !!!!!
lucaferrario
C'est la réponse la plus simple.
joaerl
35

Pouvez-vous essayer de récupérer une nouvelle copie du répertoire parent?

Edit: Pour être un peu plus précis, je voulais suggérer de monter d'un niveau et de supprimer le répertoire contenant. Puis faites un

svn update --set-depth infinity

pour remplacer le répertoire.

Rob Wells
la source
J'ai essayé cela mais pour une raison étrange, je me retrouve avec un répertoire vide. Je ne comprends pas ...
e-satis
Un <code> svn update blabla </code> explicite du parent devrait également fonctionner.
jmanning2k
@ jmanning2k, c'est ce que je pensais aussi, mais l'OP a dit qu'il avait essayé et que cela n'avait pas fonctionné.
Rob Wells
Pour clarifier, j'ai suggéré à --set-depth infinitycause de ceci: stackoverflow.com/questions/866835/…
Wim Coenen
1
Cela nécessite tellement plus de votes positifs ... une solution rapide et relativement propre (pour les normes svn).
Dino
6

J'ai ajouté un répertoire à svn, puis j'ai accidentellement supprimé le dossier .svn à l'intérieur.

j'ai utilisé

svn delete --keep-local folderName

pour résoudre mon problème.

Alexandre
la source
Cela a fonctionné pour moi lorsque mon IDE a ajouté un répertoire, puis j'ai déplacé un répertoire du même nom en place avant qu'il ne soit validé.
quellish le
essayé, mais ne pouvait toujours pas s'engager. J'ai utilisé svn checkout --force [url]ce qui a recréé le dossier .svn
Lex
4

Je viens de faire 'svn revert / blabla' et cela a fonctionné, le dossier est de retour et je peux svn le supprimer

Mala
la source
Merci. J'ai eu ce problème et j'ai essayé votre suggestion et cela a fonctionné.
Boric
3

L'erreur «Répertoire 'blah / .svn' contenant la zone d'administration de la copie de travail est manquante» s'est produite lorsque j'ai essayé d'ajouter le répertoire au référentiel, mais je n'avais pas assez de privilèges de système de fichiers pour le faire. Le répertoire n'était pas déjà dans le référentiel, mais il prétendait être sous contrôle de version après l'échec de l'ajout.

L'extraction d'une copie du répertoire parent vers un autre emplacement et le remplacement du dossier .svn dans le répertoire parent de la copie de travail m'ont permis d'ajouter et de valider le nouveau répertoire avec succès (après avoir corrigé les autorisations de fichier, bien sûr).

Rob DiCiuccio
la source
2

Nous utilisons maven et svn. C'est une erreur de consignation du répertoire cible dans SVN qui a causé cette erreur. Supprimer cela a tout corrigé, si cet indice aide quelqu'un.

Madu
la source
Supprimer quoi / d'où exactement?
DerMike
maven crée le répertoire "cible" lors de la construction. Habituellement, personne n'est censé enregistrer celui-ci. Un accès accédant a provoqué un problème d'autorisation lors de la prochaine vérification, ce qui a créé cette erreur. La suppression du répertoire "cible" de SVN a résolu le problème.
Madu
2

J'ai essayé svn rm --force /path/to/diren vain mais j'ai fini par courir svn upet cela m'a corrigé.

Nathan JB
la source
1

J'ai eu cette erreur récemment, lorsque les fichiers ont été exclus par les paramètres de mes globaux SVN. L'erreur était particulièrement désagréable puisque j'ai également supprimé les fichiers directement du référentiel - et cela signifiait que les solutions ci-dessus refusaient ne fonctionneraient pas. Dans ce cas, la suppression manuelle du répertoire .svn du répertoire que j'ai supprimé de SVN m'a permis d'exécuter une mise à jour qui m'a ensuite permis de valider.

Casebash
la source
1

J'ai eu le même problème, lorsque j'essayais de changer "C: \ superfolder"

Messages d'erreur:

Directory 'C:\superfolder\subfolder\.svn'
containing
working copy admin area is missing
Please execute the 'Cleanup' command.

Après avoir essayé de faire un "nettoyage", j'ai eu l'erreur suivante:

 Cleanup failed to process the following paths:
 C:\superfolder\
'C:\superfolder\subfolder\' is not a working copy directory

Solution:

  1. Supprimer le dossier "sous-dossier"
  2. Nettoyez le dossier "superfolder"
  3. Essayez à nouveau de changer le dossier "superfolder"

cela a fonctionné pour moi. Veuillez me faire savoir si cela fonctionne également pour vous.

Andreas
la source
1

J'ai eu cette erreur récemment. Cela était dû au fait que root possédait quelques fichiers dans le répertoire, ce qui donnait cette erreur.

Après avoir changé les autorisations, tout a fonctionné comme prévu.

JJ
la source
1

Je n'ai pas beaucoup compris de vos messages. Ma solution est

  1. Coupez le dossier problématique et copiez-le vers un emplacement.
  2. Faites Get Solution From Subversion dans un autre répertoire de travail (juste un nouveau).
  3. Ajoutez votre dossier enregistré à la nouvelle copie de travail et ajoutez-le en tant que projet existant (s'il s'agit d'un projet comme dans mon cas).
  4. Commettre;
M'vy
la source
1

J'ai eu ce problème. Déplacez simplement blabla temporairement vers un autre emplacement, dites à svn de le rétablir, puis déplacez-le en arrière. Il est traité comme un nouvel ajout. Facile!

Borique
la source
1

Le plus simple qui m'a aidé:

rm -rf _dir_in_question_
svn up

Si vous avez des modifications dans le répertoire problématique, ce n'est pas une bonne solution pour vous.

allprog
la source
1

Je suis tombé sur ce problème lors du remplacement d'une bibliothèque d'API tierce par une version plus récente, et aucune des solutions ici n'a vraiment fonctionné pour moi car je voulais remplacer la version SVN par la version locale. Ma solution était la suivante:

1) Déplacez le dossier incriminé dans mon répertoire personnel, supprimez-le de SVN et validez:

mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"

2) Remettez le dossier, ajoutez-le à SVN et validez à nouveau:

mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"

Légèrement irritant de devoir s'engager deux fois, mais cela semble avoir bien fonctionné.

Jamie Brown
la source
J'aime généralement travailler sur le code séparément de ma copie de travail du repo (les IDE, les compilateurs, les analyseurs d'erreurs, etc. n'aiment pas .svn, et il n'y a pas de commande 'TOUT LE MONDE IGNORE .SVNs SAUF SVN!' Dans Eclipse afaik); cela signifie que le processus de validation SVN de base pour moi est: 1. l'extraction de la copie de travail du dépôt 2. supprimer le répertoire racine du projet J'ai une mise à jour pour 3. copier et coller le répertoire du projet mis à jour dans le répertoire parent du projet dans la copie de travail 4. svn add --force <nomproj> 5. commit. Cela fonctionne généralement, mais peut occasionnellement générer l'erreur de l'OP. Le correctif de Jamie Brown a fonctionné dans mon cas
CCJ
0

Juste au cas où quelqu'un voudrait encore une autre solution:

  1. Enregistrez votre nouveau dossier en tant que «nomdossier2»
  2. Allez dans le navigateur de dépôt Tortise SVN
  3. Renommez "foldername2" en "foldername"
  4. Dans l'explorateur Windows, effectuez une mise à jour

J'espère que ça aide quelqu'un.

-Ev

Ev.
la source
une solution Windows uniquement.
Raptor
0

Pour moi, le même problème s'est produit lorsque j'ai tous les deux:

  • supprimé ( --force) un fichier .map
  • ajouté * .map à svn:ignoreviasvn propedit svn:ignore .

Ma solution était de:

  1. annuler les modifications apportées à la propriété
  2. valider les modifications des fichiers
  3. extraire une nouvelle copie du référentiel (hélas!)
  4. changer la propriété et valider
18446744073709551615
la source
0

J'ai eu ce problème lorsque j'essayais d'ajouter un répertoire à svn. Je l'ai résolu en allant dans le navigateur de repo. Cliquez avec le bouton droit dans la fenêtre de gauche, choisissez Ajouter un dossier et ajoutez le répertoire directement dans le navigateur du référentiel.

J'ai ensuite supprimé le répertoire localement (après la sauvegarde bien sûr), j'ai fait un nettoyage et une mise à jour svn et tout fonctionnait à nouveau.

Grain
la source
Je pourrais ajouter que ceci est ajouté à mon fichier "svn sucks".
Speck
0

Tout d'abord, extrayez le projet dans votre système dans un dossier. Supprimez ensuite le dossier .svn du projet en conflit et copiez le dossier .svn du nouveau dossier d'extraction et collez-le dans votre dossier de copie de travail. Ensuite, le problème est résolu.

Jaideep Singh Raikwar
la source
0

Une tâche courante que j'ai rencontrée était de devoir prendre un répertoire de dépôt en préparation et le copier dans un autre dépôt - à la fois sous SVN et tous deux portant le même nom. La façon dont cela a fonctionné pour moi était la suivante:

svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A
texasdave
la source