Comment vérifier la copie de travail de Subversion

J'ai une copie de travail Subversion avec au moins un fichier manquant (la copie locale est supprimé lors de la fixation de l'arbre de conflit). C'est drôle parce que le fichier est versionné, il apparaît dans le référentiel, l'arbre de résolution des conflits a été de 100% local (c'est arrivé sur la mise à jour et je n'ai pas commettre par la suite) et j'ai couru "svn cleanup" plusieurs fois, mais aucun de mes clients Subversion (ligne de commande svn et TortoiseSVN) permet de détecter la copie de travail est endommagé. Même pas de revenir tous les changements obtenu le fichier.

Je vais le corriger comme d'habitude (frais de caisse ailleurs et les modifications de copie avec WinMerge); en fait, j'ai une autre question:

Comment pouvez-vous tester la validité d'une copie de travail?

Bien sûr, vous pouvez toujours vérifier une nouvelle copie et l'utilisation d'un utilitaire de comparaison de fichiers, mais... n'est-il pas une meilleure façon? Est-il un outil pour vérifier une copie de travail équivalent à svnadmin verify?

=== Mise à JOUR ===

J'ai eu beau réponses avec des astuces pour éviter la copie de travail de la corruption, mais ma question était plus sur la ligne de trouver une méthode pour être sûr à 100% que la copie de travail est à la fois cohérent et en lien avec le réel contenu du référentiel; dans d'autres œuvres, d'une copie de travail de l'équivalent de la svnadmin vérifier commande.

Jusqu'à présent, il ressemble:

  • Subversion ne pas fournir un tel outil, et il est possible que le SVN format de données ne permet même pas à l'écrire.
  • La mise à jour vers une révision est une technique qui semble trouver (et corrigé) quelques questions, même si vous avez souvent besoin de revenir en arrière et en avant pour une ancienne version et je suppose qu'il peut seulement détecter les fichiers manquants si elles ont été modifiées dans la révision de la plage.
  • De vérifier une nouvelle copie de travail ressemble à la seule fiable à 100% méthode.

source d'informationauteur

  1. 3

    Cela ressemble à un problème que j'ai connu il y a quelques temps: svn - fichier de la copie de travail semble "perdu"

    citant wcoenen la réponse textuellement:

    SVN 1.6.1 clients (y compris les
    TortoiseSVN) avait un bug où les dossiers
    parfois, à tort, être mis à
    la profondeur de "vide". Cela provoque la
    les symptômes que vous décrivez. (Notez qu'il est
    possible que le dossier a été faite
    "vides" en svn 1.6.1 et est resté
    de cette façon, même si vous l'avez déjà
    mis à niveau vers une version plus récente de client svn dans le
    la moyenne du temps.)

    De le fixer, utiliser la fonction "mise à jour
    révision" élément de menu dans le menu TortoiseSVN et
    sélectionnez la profondeur "récursives,"

  2. 2

    Si vous faites un clic droit sur le fichier, sous le SVN menu je crois qu'il existe une commande Diff. Cela permettra d'ouvrir et de mettre en évidence les différences entre la version locale et les pensions de version je crois.

    Vous pouvez également exécuter les diff de la ligne de commande si vous le souhaitez.

  3. 1

    J'ai eu des problèmes similaires quand j'ai commencé à travailler avec SVN en utilisant Tortue sur Windows. Chaque fois que j'avais besoin d'une copie d'un dossier - par exemple lors de la création d'un nouveau plug-in qui a été basé sur un autre, déjà existant - je gaiement copie+collé à l'intérieur de la copie de travail.

    Ce que je ne savais pas c'est que quand vous faites cela, vous copiez le long de la .svn métadonnées répertoire. Cela provoque la subversion sans fin de la confusion - si vous travaillez avec un client graphique, le nouveau répertoire semble être correctement vérifiée, et le client vous montre une assiette propre après chaque commit. Mais, le nouveau répertoire n'est jamais vérifié dans.

    Vous remarquez lorsque vous découvrez une nouvelle copie de travail ailleurs, et puis vous êtes foutu parce que ces fichiers n'ont jamais été sous contrôle de version. M'a coûté une demi-journée pour fixer l'époque.

    Lorsque vous avez besoin de dupliquer un répertoire dans une copie de travail, toujours à l'exportation d'abord, puis de l'ajouter.

  4. 1

    Jusqu'à présent, je vais supposer qu'il n'y a pas un moyen fiable de le faire, sauf si vous faites un nouveau commit et de comparer les deux arborescences de répertoires. Si un .snv répertoire manque de données mais n'est pas réellement endommagé, il n'y a simplement pas assez d'informations dans la copie de travail afin de détecter certains fichiers ont disparu.

    Alors qu'il est possible que WC-NG changements ce pour le meilleur (ou pas), format actuel n'est pas solide comme le roc.