svn: Item & lt; dossier & gt; n'est pas à jour

[réponse auto-sélectionnés par le système de récompense contre ma volonté]

Je suis en utilisant subclipse, et toujours lors de la suppression d'un dossier dans Eclipse, et d'essayer de le commettre, les erreurs suivantes lever:

svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)

La suppression et la validation via la ligne de commande fonctionne très bien, mais quel est le problème avec le faire via le subclipse? Quelqu'un est-il plus confronté à ce problème?

(J'ai connu ce problème avec Ubuntu 9.10 et 10.04; la dernière Éclipse de la version; et subclipse 1.4 - que les prochaines versions de subclipse ont beaucoup plus de bugs)

--mise à jour: Sa quand j'ai supprimer les dossiers pas les fichiers

source d'informationauteur Tom Brito

  1. 2

    Subclipse a beaucoup de problèmes de ce genre. Il fonctionne 90% du temps, et puis il NE fonctionne tout simplement PAS comme il se doit! Je suis à l'aide de subclipse, car il est très bien intégré dans eclipse, et quand j'ai un problème ou certains grands mouvements nécessaires dans le svn (comme la fusion de certains de branche) - je utiliser Tortoisse.

    J'ai eu le problème avec le répertoire comme vous. Alors je viens de lancer la commande TortoiseSVN comme @luiscolorado suggère, et il a aidé. La tortue est si grand outil (il a de nombreuses fonctionnalités pour comparaison, l'application de correctifs, l'obtention des correctifs et ainsi de suite.).

    Aujourd'hui, j'ai eu un problème quand j'ai supprimé un fichier, et que quelqu'un avait changé le même fichier! Puis subclipse montre conflit (jusqu'à ce point, tout est ok), j'ai donc voulu revenir! Mais alors le bouton revert est manquant (disparaît lorsque inconflict mode!) alors, je dois faire fusionner, et fusionner ne fonctionne pas, jette un certain genre d'erreur. Je n'ai pas pris la peine de lire (je devrais peut-être lire et fichier comme un bogue de subclipse responsables ;-(), je savais que le tortoisse de travail, et vous savez quoi, il a travaillé. Il y avait un REVERT option.

    Donc @Tom Brito, essayez de la ligne de commande, essayez Tortoisse, et puis vous pouvez regarder le subclipse changelog et de soumettre un rapport de bogue. Je pense que subclipse juste oublie de nous montrer certaines répertoire des modifications et des mises à jour (ou il est conçu pour ne pas le faire?), mais j'ai peut-être tort.

  2. 39

    N'est pas traitée par le Subclipse FAQ?

    Chaque fois que vous voyez "out of date" dans un message d'erreur signifie que la révision de l'article dans le dépôt est plus récent que le copier dans votre copie de travail locale.

    Le solution est toujours d'exécuter une mise à jour, de sorte que votre copie de travail est à jour dans le référentiel, et puis de faire commettre à nouveau (en supposant que la mise à jour ne génère pas de conflits).

    • Pour les fichiers, ce n'est généralement assez facile de comprendre comment et pourquoi cela se produit.
    • Cependant, Subversion a également des versions dossiers, et c'est généralement avec des dossiers qui ce problème arrive souvent.

      La Subversion ne vous permet pas de supprimer/renommer un dossier OU de changer ses versionnées propriétés, à MOINS que la copie locale du dossier est à la TÊTE de la révision du dossier dans le référentiel.

    Votre prochaine question pourrait être:

    "OK, je peux peut-être comprendre, mais pourquoi mon dossier à jour? Je suis la seule personne dans ce référentiel."

    C'est une bonne question, la réponse réside dans la façon dont la Subversion fonctionne.

    Lorsque vous validez une modification à un fichier, la révision du fichier dans votre copie de travail est mis à jour que les nouvelles de révision lors de la validation terminée, cependant la version du dossier parent(s) de ce fichier n'est pas mis à jour.

    C'est parce qu'il peut y avoir ajoute/supprime les autres fichiers dans ce dossier et jusqu'à ce que vous exécutez une mise à jour, le dossier n'est pas vraiment à cette nouvelle révision.

    Ceci est appelé "mixte de travail sur la révision des copies".

    En résumé, la réponse est toujours de faire une mise à jour afin que le dossier ou le fichier est mis à jour pour son HEAD révision.

    Sur "Mixte De Travail Sur La Révision Des Copies":

    Un seul type de flexibilité est la capacité d'avoir une copie de travail contenant des fichiers et des répertoires avec un mélange de plusieurs types de travail que les numéros de révision.

    L'une des règles fondamentales de la Subversion est qu'un “push” action ne provoque pas de “tirer”, ni vice-versa.

    Juste parce que vous êtes prêt à soumettre de nouvelles modifications dans le référentiel ne signifie pas que vous êtes prêt à recevoir des modifications de d'autres personnes.

    Le fait est, chaque fois que vous lancez svn commit de votre copie de travail se termine avec un certain mélange de révisions.

    Les choses que vous venez de commis sont marqués comme ayant le plus grand travail de révisions que tout le reste. Après plusieurs commits (avec pas de mises à jour entre les deux), votre copie de travail contient un ensemble de mélange de révisions

    (et c'est pourquoi, je crois, vous ne pouvez pas reproduire votre "out of date" message à la suite, s'engage avec dossier supprimé: votre mise à jour ont permis de résoudre le "mixte" révision de l'état.)

    Des révisions mélangées ont des limitations

    Vous ne pouvez pas valider la suppression d'un fichier ou d'un répertoire qui n'est pas complètement à jour.

    Si une version plus récente de l'élément existe dans le référentiel, votre tentative de suppression sera rejetée pour vous empêcher de détruire accidentellement changements que vous n'avez pas encore vu.

  3. 6

    je pense que si vous mettez à JOUR avant que cela devrait fonctionner.. il a fait un travail pour moi

  4. 2

    Tom,

    Vous pourriez vouloir essayer de TortoiseSVN, et de mettre à jour manuellement l'espace de travail de projet. Trouver l'emplacement de votre répertoire de projet sur votre disque dur, puis essayez de TortoiseSVN (ou de la ligne de commande si c'est votre préférence) pour faire la mise à jour.

    Une cause fréquente de ce problème consiste à supprimer le répertoire sans les "informer" SVN. Par exemple, si vous supprimez manuellement le répertoire à l'aide du système d'exploitation au lieu d'utiliser SVN, vous aurez ce problème.

    Si vous avez supprimé le répertoire avant l'installation de la subversion plug-in, mais le projet existe déjà dans le référentiel, vous permettra d'expérimenter ce problème. Une solution, dans ce cas, serait de recréer le répertoire, la mise à jour/validation, puis de supprimer à nouveau le répertoire.

    Bonne chance.

  5. 2

    Ma solution à ce problème est

    1. Supprimer tous les éléments dans le dossier
    2. S'engager à référentiel
    3. Dossier de mise à jour à la TÊTE de
    4. Supprimer le dossier dans Eclipse
    5. S'engager à référentiel

    Un peu lourd, peut-être, mais il travaille toujours

  6. 2

    Il y a une solution simple, sans installer de logiciel supplémentaire. J'ai aussi eu ce "problème" et ce que vous pouvez faire est la suivante:

    1) ouvrez la vue Repository SVN
    2) allez dans le dossier que vous voulez vous débarrasser de et de le supprimer
    3. retournez à la vue de java
    4) mettre à jour le dossier de votre projet vous réellement supprimer /mettre à jour votre projet travaux

    Qui a résolu le problème dans mon cas, que la mise à jour seulement récupéré les fichiers que j'ai supprimé

  7. 0

    La seule façon de travailler dans le même cas est via la ligne de commande. Le subclipse est pas encore parfait..