Impossible de mettre à niveau le SVN de la copie de travail

J'ai un très très grand repo svn. Lorsque j'essaie de l'utiliser (commit, update, etc.) il dit qu'il y a des verrous.

Quand je lance "svn cleanup', il est dit que la copie de travail est trop vieux et j'ai besoin de le mettre à jour.

Quand je lance "svn mise à niveau", il s'exécute, mais ne dit rien.

J'ai aussi couru 'svnadmin de mise à niveau" sur le repo, juste au cas où.

J'ai la dernière installé TortoiseSVN.

Normalement, si j'avais SVN quelque chose d'étrange, j'avais de déplacer les fichiers, mettre à jour, de déplacer les fichiers de retour, mais comme je l'ai mentionné plus tôt, c'est un très GRAND repo.

Toute aide serait appréciée.

Merci!

Des messages spécifiques:

>svn update
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '*****' locked.
svn: E155004: '*****' is already locked.

>svn cleanup
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '*****' is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first.

>svn upgrade

>

Mise à jour de 1:
J'ai installé un 1.7.Client X et a essayé de lancer un nettoyage. Il s'est plaint que l'opération n'était pas une copie de travail, pour quelque raison. J'ai essayé une mise à jour avec la même 1.7.X client et j'ai obtenu le message suivant:

>"c:\Program Files\SlikSvn\bin\svn.exe" update
svn: E155021: This client is too old to work with the working copy at '*****' (format 31).
You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change

Ainsi, ce client les choses les pensions de titres sont au format 31. Tortoisesvn pense que c'est le format 29. Maintenant, je suis de plus en plus confus.

Mise à jour 2:
Réponse à @David W

Is this about a working copy or the repository?

De la copie de travail. Si j'ai essayé svnadmin de mise à niveau sur le repo. Cependant, la svnadmin que j'ai utilisé était la 1.8.1. J'ai juste essayé de mettre à niveau le repo avec TortoiseSVN un (1.8.10), mais qui n'a pas de résoudre le problème.

is this about a file that's locked because someone locked it, or because your working directory is locked due to an incomplete

Je suis le seul à utiliser le repo, je ne connais personne d'autre ne l'a enfermé. C'est probablement incomplète, op.

J'ai couru svn status avec 1.8.10, et que rien n'avait un "K". Il y avait des fichiers avec un "L", et l'autre avec un '?'. Tous les éléments énumérés sont des répertoires, des fichiers, à l'exception de celui marqué avec un '?'.

Si j'ai couru un "svn lock --force dirname", il répondrait que ce nœud spécifique "n'est pas un fichier". Quand je l'ai couru sur le fichier marqué avec un '?', il a répondu que ce nœud 'n'a pas été trouvé".

Then, there is a locked working directory because of an incomplete operation...

Oui, vous l'avez appelé. C'est pourquoi toutes les choses sont marqués avec un "L", j'imagine.

Quand j'ai couru un nettoyage (1.8.10) il m'a donné la même erreur que j'ai rapporté dans mon intiial question (format 29 trop vieux pour ce format 31 client).

Remember that you can always delete a working directory and create a new one

Yep. Si je supprime le répertoire de la copie de travail et de frapper la mise à jour, il se plaint qu'il est verrouillé. Je ne peux pas supprimer le cadenas, la " cause de l'incompatibilité de format. Je peux théoriquement viens de re-commander l'ensemble du repo, puis copiez les choses, mais l'opération est de 12 go (de 210 000 fichiers).

Be careful about mixing up Subversion clients

Donc, j'étais pas au courant que j'ai eu deux clients, mais je n'en ai seulement utiliser TortoiseSVN (1.8.10). Je ne l'ai découvert aujourd'hui que j'ai eu deux quand j'ai essayé de résoudre les problèmes.

* MISE À JOUR 3: RÉSOLUTION *
À l'aide de @David W conseils, voici comment j'ai résolu le problème:
1) Sauvegardé mon .svn dossier
2) Téléchargé un SQLite editor à partir de https://github.com/sqlitebrowser/sqlitebrowser/releases
3) Ouvert mon wc.le fichier db et a parcouru le WC_LOCK table. Il y a 1 l'entrée dans cette table, qui je l'ai enlevé.
4) Essayé de lancer un nettoyage en utilisant TortoiseSVN (1.8.10), qui, auparavant, se sont plaints sur les verrous. Enfin, cela a fonctionné!
5) a Essayé d'exécuter des commandes dans mon repo (mise à jour, validation, etc.), et tout a été heureux.

Merci à tous ceux qui ont aidé, en particulier par @David W pour ne pas donner vers le haut sur moi.

C'est probablement une ligne de commande SVN pas liées à la Tortue: il dit 1.8.1 alors que la dernière Tortue serait 1.8.10. Étant donné qu'il dit c'est un 1.7.x WC (format 29), vous pourriez essayer d'obtenir un 1.7 ligne de commande SVN et en cours d'exécution svn cleanup avec qui avant de retourner à votre 1.8.x client pour mettre à niveau.
J'ai aussi essayé les deux commandes via TortoiseSVN avec la même erreur. Théoriquement, c'est un 1.8.X client de tenter de la commande. Je vais essayer ce que vous avez dit et écrire les résultats. Merci!
J'ai essayé ta suggestion et édité la question avec les résultats. TL;DR: 1.7 client pense que les pensions de titres sont au format 31, tortoiseproc (1.8.10) et svn (1.8.1) deux pense que c'est à 29 ans. Tellement confus.

OriginalL'auteur Morfie | 2014-10-02

  1. 5

    J'ai un très très grand repo svn. Lorsque j'essaie de l'utiliser (commit, update, etc.) il dit qu'il y a des verrous.

    Est-ce à propos d'un copie de travail ou la référentiel? De deux choses différentes. Aussi, est-ce à propos d'un fichier est verrouillé parce que quelqu'un verrouillé ou parce que votre répertoire de travail est bloqué en raison d'une incomplète

    Vous pouvez avoir un de verrouillage sur un fichier qui vous empêche de faire un commit. À partir de la ligne de commande, vous pouvez faire un svn status et de voir le K à côté du fichier verrouillé. Vous pouvez ensuite utiliser svn lock --force à voler le verrou, et d'enregistrer vos modifications. (Tant qu'il n'y a pas de crochet dans le référentiel qui vous empêche de voler des verrous).

    Puis, il y a un blocage de répertoire de travail en raison d'une opération incomplète. Dans ce cas, vous verrez un L lorsque vous faites un svn status. Dans ce cas, vous pouvez généralement faire un svn cleanup dans le répertoire racine de la copie de travail (Où l' .svn dossier se trouve.)

    N'oubliez pas que vous pouvez toujours supprimer un répertoire de travail et en créer un nouveau. Soyez prudent à propos de mélanger les clients Subversion. À un moment, il ne semblait pas beaucoup d'importance, mais dans la Révision de la 1.6, 1.7, 1.8 et 1.9, la structure de la copie de travail a changé et peut ne pas être compatible avec les clients de l'exécution d'autres révisions.

    Mise à jour 2

    Yep. Si je supprime le répertoire de la copie de travail et de frapper la mise à jour, il se plaint qu'il est verrouillé. Je ne peux pas supprimer le cadenas, la " cause de l'incompatibilité de format. Je peux théoriquement viens de re-commander l'ensemble du repo, puis copiez les choses, mais l'opération est de 12 go (de 210 000 fichiers).

    La suppression d'un répertoire et ensuite de faire un svn up ne nettoie pas le verrouillage de problème. J'ai voulu supprimer tout le répertoire de travail, et de refaire une svn co. Vous n'avez pas à la caisse de l'ensemble des pensions. Vous n'avez qu'à vérifier ce que vous avez besoin. Avez-vous besoin de toutes les 210 milliers de dossiers? J'en doute:

    $ svn co http://server/repo            # NOOOO!
$ svn co http://server/repo/trunk      # A bit better, but do you need all
                                       # the projects under Trunk?
$ svn co http://server/repo/trunk/foo  # Now, I'm just checking out foo
$ svn co http://server/repo/trunk/bar  # Now, I'm just checking out bar

    Ce qui vérifie les deux répertoires: Un pour foo et un pour bar.

    Si vous avez vraiment, vraiment envie de la caisse de l'ensemble du tronc, utilisez le --depth à peu checkout ce dont vous avez besoin:

    # Checking out trunk, but only getting the project directories
$ svn co http://server/repo/trunk --depth=immediates
$ svn up --set-depth=infinity foo
$ svn up --set-depth=infinity bar

    Ici, je suis dans la théorie de la vérification de l'ensemble du tronc, mais je suis seulement un vide maître répertoires de projet. Je ne fais que récupérer des fichiers à partir de projetsfoo et bar. Cependant, foo et bar partager un répertoire de travail. Disons que je commence une longue mise à jour sur foo, puis-je aller à bar et d'essayer de s'engager. Je vais recevoir un avertissement que le répertoire de travail est verrouillé. Je ne peux pas faire deux commandes de Subversion sur le même répertoire de travail, même si elles sont dans les différentes sections du répertoire de travail.

    Donc, j'étais pas au courant que j'ai eu deux clients, mais je n'en ai seulement utiliser TortoiseSVN (1.8.10). Je ne l'ai découvert aujourd'hui que j'ai eu deux quand j'ai essayé de résoudre les problèmes.

    Si vous installez la Tortue, vous pouvez également installer la ligne de commande de Subversion client qui est une option à installer. Je le recommande fortement! Ne pas utiliser une ligne de commande client téléchargé à partir ailleurs (comme SlikSVN ou CollabeNet. Ce n'est pas que ces clients sont mauvais. C'est que vous devez utiliser le client de ligne de commande qui vient avec votre version de TortoiseSVN afin de garantir une certaine parité entre les deux clients Subversion.

    Nettoyage vs Mise à niveau ou Svnadmin

    Il est très facile d'obtenir ces confus. Vous ne devriez pas être à l'aide de svnadmin de commandes sur votre répertoire de travail. Le svnadmin est pour le serveur. Le problème que vous avez est strictement client.

    Comme de la Subversion déplacé, passant de 1,6 à 1,7 à 1,8 et maintenant à 1,9, le upgrade allons mettre à jour votre répertoire de travail pour le nouveau format. Une fois fait, vous ne pouvez pas revenir à l'ancien format. La mise à niveau vers la 1.8 format, 1.7 et 1.6 clients n'auront plus de travail.

    De nettoyage est pour aider à supprimer les verrous en raison incomplète Subversion des commandes du client.

    Merci! J'ai répondu par édition mise à Jour de 2 à ma question ci-dessus.
    Voir ma réponse à votre réponse.
    Je reçois le message d'erreur quand j'execute les commandes contenues dans la racine de la Copie de Travail. Ce WC est l'extrait de la racine de l'ensemble des pensions. Donc, à partir de la racine du check-out, WC de l'opération, des erreurs. Je souhaite que ce n'était qu'un sous-répertoire. En termes de svnadmin, je n'ai pas l'exécuter sur un répertoire de travail. Je connais mieux. J'ai été en cours d'exécution sur le serveur, sur le repo. En termes de mise à niveau, ce repo a été de 1,8 depuis la 1.8 est sorti. Il sert à être 1.7, mais c'était il y a longtemps. Enfin, j'ai fait installer le cmdline TortoiseSVN des animaux, que j'utilise. Sachant tout cela, est ma seule option de CO tout le repo? TY!
    Ne pas commander l'ensemble des pensions de! Juste la partie de l'opération dont vous avez besoin. Vous pouvez les extraire juste le répertoire/projet sur lequel vous travaillez.
    Tout d'abord, la "Vérification de tronc, mais seulement obtenir les répertoires de projet" a bien fonctionné. J'ai été en mesure d'interagir sans problème. Le problème est que des 84 de la racine des répertoires/projets dans le repo, je utiliser activement sur 34 d'entre eux dans une journée donnée. Donc, je peux svn up 34 dirs, mais je pourrais aussi bien le remake de la chose entière. Puis resynchroniser mes changements de l'ancien vers le nouveau. Est-il possible de supprimer manuellement les serrures sans l'aide d'une commande SVN?

    OriginalL'auteur David W.