Erreur SVN – Pas une copie de travail

Si vous obtenez une copie “pas une copie de travail” lorsque vous effectuez un svn cleanup récursif de svn cleanup je pense que vous avez un répertoire qui devrait être une copie de travail (c.-à .svn répertoire .svn au niveau supérieur le dit), Répertoire .svn . Dans ce cas, vous pouvez simplement supprimer / déplacer ce répertoire, puis effectuer une mise à jour locale (par exemple, rm -rf content; svn checkout content ).

Si vous obtenez une erreur de not a working copy qui ne fonctionne pas, cela signifie que Subversion ne peut pas trouver un répertoire .svn correct. Vérifiez s’il y a un répertoire .svn dans le contents

La solution idéale est une nouvelle caisse si possible.

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

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

Oops! corriger les permissions … alors:

 $ 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 déplacer des papers et faire tourner svn up (qui fonctionnait pour l’OP) ne l’a pas réparé. 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. Copier une sauvegarde des dossiers impactés
2. SVN annule les dossiers impactés
3. Coller 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’append 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: Renommez le répertoire qui n’est pas une copie de travail. Récupérez / mettez à jour / restaurez ce répertoire. Déplacez les fichiers du répertoire renommé vers les nouveaux changements de validation.

Raison: Vous avez apporté des modifications à certains fichiers dans le répertoire .svn, cela interrompt la “copie de travail”

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

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 append le répertoire. Tous les fichiers contenus dans le répertoire seront ajoutés par défaut.

Même chose, je devais mettre à jour un dossier “consortingb”:

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 dans le dossier racine. Ça marche!!!

C’est ce que j’ai fait:

1. renommer le tronc en tronc_
2. créer un nouveau coffre de dossier
3. Re-checkout et interrompre le processus après que quelques fichiers sont extraits
4. Déplacer les fichiers du trunk_ vers le tronc
5. Ne svn nettoyer
6. Faites svn update. Cela mettra à jour l’état des fichiers et tous vos fichiers seront versionnés.

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

svn: Le repository de ‘svn: // repourl / reponame / foldername’ a uuid ‘m / reponame’, mais le WC a ‘b5b39681-0ff6-784b-ad26-2846b9ea8e7d’

Chaque repository de subversion a un identifiant unique (uuid). Subversion utilise ceci pour s’assurer que le référentiel est réellement le même quand on fait des choses comme la commutation. Vous devriez probablement changer le 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 nouveaux outils convertissent automatiquement le format, mais les anciens ne fonctionnent plus avec la copie convertie.

Vous devez avoir supprimé un fichier SVN de base de votre projet (qui sont des fichiers en lecture seule). De ce fait, 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 en utilisant “Winmerge” et validez les modifications dans votre dernière extraction.

@JesperE mentionne que vous devez changer l’uuid. Ce qui suit devrait vous aider à y parvenir.

Sur SVN 1.5+, vous pouvez faire svnadmin setuuid; vous pouvez alors vérifier qu’il a été configuré correctement avec svnlook uuid. Sur les versions antérieures de SVN, le processus est 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 pense que cela 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 enlevé mes commentaires. ]

Avait 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é mis à jour (et avait mis à jour la copie de travail), mais pas Slik, Tortoise fonctionnait correctement, mais les lignes de commande ont échoué avec:

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

Supprimer à la fois Tortoise et Slik, puis réinstaller Tortoise avec les outils de ligne de commande activés, a corrigé cela pour moi.

pour mac: – prendre la caisse du côté du serveur et une nouvelle fenêtre s’ouvrira pour sélectionner le répertoire de votre machine locale plutôt que de mettre tout votre code dans le dossier sélectionné puis ouvrir le côté local de svn et append et valider le projet

Aujourd’hui, j’ai trouvé le même numéro /FILE_NAME/ is not a working copy du matin et j’ai passé plus de deux heures à le résoudre. Après long de RND et Google, j’ai trouvé une solution et c’est CHECKOUT .

1. SUBVERSION de SUBVERSION au local comme nouveau projet.
2. Changez une partie du code dans le fichier java et COMMIT le projet.
3. Ça marche pour moi

J’espère que cela vous sera utile.

Supprimez le dossier .svn présent sur votre ordinateur local. Appuyez sur l’icône Windows et tapez .svn, supprimez le dossier entier. Cela a fonctionné pour moi.

Récemment, j’utilisais d’autres développeurs Mac j’avais la même situation, le problème était; D’abord, je devais 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.