Erreur SVN - Pas une copie de travail

Récemment, notre serveur svn a été changé et nous avons fait un commutateur svn.

Étant donné que la copie de travail avait une énorme quantité de ressources non versionnées, la copie de travail a été verrouillée et nous avons commencé à changer de dossier par dossier pour tous les dossiers sous svn, ce qui fonctionne parfaitement.

Mais au plus haut niveau du référentiel, lorsque j'essaie de mettre à jour des fichiers, j'obtiens le svn: Working copy '.' erreur verrouillée et le nettoyage n'aide pas non plus. Quand je fais le nettoyage, j'obtiens des erreurs comme celles-ci - svn: 'content' n'est pas un répertoire de copie de travail

Un nouveau paiement n'est PAS une option du tout. Y a-t-il d'autres façons de nettoyer et de libérer les verrous et de faire le commutateur complètement?

EDIT: Le dernier paragraphe de la réponse de JesperE

Si vous obtenez "pas une copie de travail" lorsque vous effectuez un "nettoyage svn" récursif, je suppose que vous avez un répertoire qui devrait être une copie de travail (c'est-à-dire le répertoire .svn au niveau supérieur le dit), mais il manque son propre répertoire .svn. Dans ce cas, vous pouvez simplement supprimer / déplacer ce répertoire, puis effectuer une mise à jour locale

semble être la solution au problème dans le référentiel. J'ai identifié ces dossiers et fait une nouvelle vérification de ces dossiers spécifiques et wow, les verrous sont libérés lors du nettoyage suivant! Merci beaucoup JesperE !!

Mais, je ne peux toujours pas comprendre l'erreur de commutateur svn qui se lit maintenant comme,

svn: Le référentiel à 'svn: // repourl / reponame / foldername' a uuid 'm / reponame', mais le WC a 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Des idées ?

Si vous obtenez un "pas une copie de travail" lorsque vous effectuez un récursif, svn cleanupje suppose que vous avez un répertoire qui devrait être une copie de travail (c'est-à-dire que le .svnrépertoire au niveau supérieur le dit), mais il lui manque son propre .svnrépertoire. Dans ce cas, vous pouvez simplement supprimer / déplacer ce répertoire, puis effectuer une mise à jour locale (c. rm -rf content; svn checkout content-à-d.).

Si vous obtenez une not a working copyerreur, cela signifie que Subversion ne peut pas y trouver un .svnrépertoire approprié . Vérifiez s'il y a un .svnrépertoire danscontents

La solution idéale est un nouveau contrôle, si possible.

Je suis entré dans une situation similaire ( svn: 'papers' is not a working copy directory) d'une manière différente, alors j'ai pensé publier mon histoire de bataille (simplifiée):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

Oups! fixer les autorisations ... puis:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

Et même s'éloigner paperset courir svn up(ce qui fonctionnait pour l'OP) ne l'a pas corrigé. Voici ce que j'ai fait:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

Ça a marché.

Je l'ai résolu par

1. Copiez une sauvegarde des dossiers concernés
2. SVN rétablit les dossiers impactés
3. Collez les fichiers depuis la sauvegarde

Dans mon cas, le problème était dû à la suppression des fichiers .svn.

Peut-être que vous venez de copier l'arborescence du dossier et d'essayer d'ajouter le plus bas.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

dans ce cas, vous devez valider le répertoire au niveau supérieur.

Solution: renommer le répertoire qui n'est pas une «copie de travail» Extraire / mettre à jour / restaurer à nouveau ce répertoire Déplacer les fichiers du répertoire renommé vers de nouvelles modifications de validation

Raison: vous avez apporté des modifications à certains fichiers dans le répertoire .svn, cela rompt la «copie de travail»

Si vous avez créé un fichier dans un nouveau répertoire, au lieu de «svn add newdir / newfile», utilisez «svn add newdir» car vous devez ajouter le répertoire. Tous les fichiers à l'intérieur du répertoire seront ajoutés par défaut.

Je viens de recevoir "pas une copie de travail", et pour moi, la raison était l'Automouter sur Unix. Juste un nouveau "cd / path / to / work / directory" a fait l'affaire.

Pareil, j'avais besoin de mettre à jour un dossier 'contrib':

1. Déplacé l'ancien dossier,
2. Copié le nouveau
3. Copié les dossiers .svn dans chaque nouveau dossier (seulement trois dans mon cas).

Dans mon cas aussi, le problème était dû à la suppression des dossiers .svn.

Résolu.

J'ai essayé de coller le dossier .svn du sous-dossier vers le dossier racine. Ça marche!!!

C'est ce que j'ai fait:

1. renommer le tronc en trunk_
2. créer un nouveau tronc de dossier
3. Revérifier et interrompre le processus après l'extraction de quelques fichiers
4. Déplacer les fichiers de trunk_ vers trunk
5. Faire le nettoyage svn
6. Faites la mise à jour svn. Cela mettra à jour l'état des fichiers, puis tous vos fichiers seront versionnés.

Je rencontre également ce problème dans l'opération diff svn, il a été causé par un chemin de fichier incorrect, vous devez ajouter './'pour indiquer le répertoire de fichiers actuel.

svn: Le référentiel à 'svn: // repourl / reponame / foldername' a uuid 'm / reponame', mais le WC a 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Chaque dépôt subversion a un identifiant unique (uuid). Subversion l'utilise pour s'assurer que le dépôt est en fait le même lorsque vous effectuez des opérations telles que la commutation. Vous devriez probablement changer l'uuid sur le serveur pour qu'il soit le même qu'avant.

Serait-ce une incompatibilité de format de copie de travail? Il a changé entre svn 1.4 et 1.5 et les outils plus récents convertissent automatiquement le format, mais les anciens ne fonctionnent plus avec la copie convertie.

Vous devez avoir supprimé un fichier de base SVN de votre projet (qui sont des fichiers en lecture seule). Pour cette raison, vous obtenez cette erreur.

Vérifiez à nouveau un nouveau projet, fusionnez les modifications (le cas échéant) de votre ancien projet SVN avec un nouveau à l'aide de "Winmerge" et validez les modifications dans votre dernière extraction.

@JesperE mentionne que vous devez changer l'uuid. Les informations suivantes devraient vous aider à y parvenir.

Sur SVN 1.5+, vous pouvez faire svnadmin setuuid; vous pouvez ensuite vérifier qu'il a été défini correctement à l'aide de svnlook uuid. Sur les versions antérieures de SVN, c'est un processus plus difficile. Voir http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

De plus, l'UUID de "m / reponame" semble suspect. Je crois que ce devrait être un nombre au format hexadécimal comme celui de la copie de travail, alors peut-être que cette action améliorera les choses tout au long :-)

[J'ai initialement commenté la réponse de @ JesperE , mais j'ai créé cette réponse pour la rendre plus évidente pour les gens et plus utile pour Google. J'ai depuis supprimé mes commentaires. ]

Eu ce même problème, il s'avère que nous avions Slik 1.6.2 ainsi que Tortoise sur la même machine. Tortoise avait été mise à jour (et avait mis à jour la copie de travail) mais Slik ne l'avait pas fait, donc Tortoise a bien fonctionné, mais les lignes de commande ont échoué avec:

svn: '.' n'est pas un répertoire de copie de travail

Supprimer Tortoise et Slik, puis réinstaller Tortoise avec les outils de ligne de commande activés a résolu ce problème pour moi.

pour mac: - prenez la caisse côté serveur et une nouvelle fenêtre s'ouvrira pour sélectionner le répertoire de votre machine locale que mettre tout votre code dans le dossier sélectionné puis ouvrir svn côté local et ajouter et valider le projet

Aujourd'hui, j'ai trouvé le même problème le /FILE_NAME/ is not a working copymatin et j'ai passé plus de deux heures pour le résoudre. Après une longue période de RND et de Google, j'ai trouvé une solution et c'est CHECKOUT.

1. CHECKOUTdu SUBVERSIONlocal au nouveau projet.
2. Modifiez une partie du code dans le fichier java et validez le projet.
3. Ça marche pour moi.

J'espère que cela vous sera utile.

Récemment, j'utilisais d'autres développeurs Mac. J'ai eu la même situation, le problème était; J'ai d'abord dû taper get repo path to terminal mais je ne l'ai pas fait, car il indique quel est votre nom d'utilisateur et votre mot de passe.

Je viens de rencontrer un cas où le répertoire .svn se trouve sur un serveur nfs sur une autre machine et où le client nfs n'exécutait pas le service de verrouillage de fichiers ( lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

Cela a disparu une fois lockddémarré sur l'hôte client nfs.

Il semble que subversion puisse produire un meilleur message d'erreur lorsqu'il a du mal à verrouiller les fichiers. C'était subversion 1.10.0

J'ai effectué une nouvelle extraction à partir du même projet vers un emplacement différent, puis copié le dossier .svn à partir de celui-ci et remplacé par mon ancien dossier .svn. Après cela, appelé la fonction de mise à jour svn et tout a été correctement synchronisé à jour.

Supprimez le dossier .svn présent sur votre ordinateur local. Appuyez sur l'icône Windows et tapez .svn, supprimez tout le dossier. Ça a marché pour moi.