svn: article <folder> est obsolète

[réponse choisie automatiquement par le système de primes contre ma volonté]svn: article <folder> est obsolète

J'utilise subclipse, et toujours quand supprimer un dossier dans Eclipse, et essayer de le commettre, ce qui suit erreurs soulèvent:

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

Suppression et commiting via la ligne de commande fonctionne très bien, mais ce qui est mal à le faire via subclipse? Est-ce que quelqu'un rencontre plus ce problème?

(j'ai vécu ce problème dans Ubuntu 9.10 et 10.04, la version dernière Eclipse et Subclipse 1.4 - que les prochaines versions de subclipse ont beaucoup plus de bugs)

--updated: Son lorsque je supprime des dossiers, pas les fichiers

Source

2010-05-10 Tom Brito

La sous-clipse présente de nombreux problèmes de ce type. Cela fonctionne 90% du temps, et ensuite ça ne marche pas comme il se doit! J'utilise subclipse, car il est très bien intégré dans eclipse, et quand j'ai un problème ou des mouvements plus importants dans svn (comme fusionner une branche), j'utilise Tortoisse.

J'ai eu la chose avec le répertoire comme vous. Ensuite, je lance simplement le TortoiseSVN comme @luiscolorado suggère, et cela m'a aidé. Tortoise est un outil génial (il a de nombreuses fonctionnalités pour différencier, appliquer des correctifs, obtenir des correctifs, etc.).

Aujourd'hui, j'ai eu un problème quand j'ai supprimé un fichier, et que quelqu'un avait changé le même fichier! Alors subclipse montre le conflit (jusqu'ici tout est ok), donc j'ai voulu revenir! Mais alors le bouton de retour est manquant (disparaît quand le mode d'inconflict!) Donc je dois faire fusionner, et fusionner ne fonctionne pas, jette une sorte d'erreur. Je n'ai pas pris la peine de lire (peut-être que je devrais lire et le déposer comme un bug pour les mainteneurs de sous-claviers ;-(), je savais que le tortoisse fonctionnerait, et vous savez quoi, cela a fonctionné.Il y avait une option REVERT

Donc, @Tom Brito, essayez la ligne de commande, essayez Tortoisse, et puis vous pouvez regarder le sous-élément changelog et déposer un bogue.Je pense que la sous-clipse oublie de nous montrer quelques changements de répertoire et mises à jour (ou il est conçu pour ne pas le faire ?), mais je peux me tromper.

Source

2010-11-30 15:12:30

J'utilise la plupart des lignes de commande (ce qui n'est pas productif, mais fonctionne ..) –

Mon ami utilise la ligne de commande pour svn et hg presque tout le temps, et il dit que c'est la seule façon productive de l'utiliser; Mais cela dépend probablement du flux de travail que l'on utilise. –

Je pense que si vous mettez à jour avant que cela devrait fonctionner .. il a travaillé pour moi

Source

2010-05-10 18:53:20 marianboda

vous voulez dire que la mise à jour avant de commettre , ne pas mettre à jour la version subclipse, j'espère. Il n'y a rien à mettre à jour (donc, le bouton de mise à jour est désactivé), je suis le seul dans cette branche svn. –

oui, j'ai ce même problème en éclipse, que les fichiers supprimés en quelque sorte ne voulait pas commettre avec la même erreur. Je ai googlé que, que je devrais mettre à jour à la tête dans le sous-menu de l'équipe, svn va détecter ces changements - la suppression de fichiers. ça ressemble à un bug pour moi. – marianboda

désolé, je le dis mal, ses fichiers ne sont pas, ses dossiers. Au fait, je vais essayer, je ne vais pas le reproduire maintenant, je ne sais pas pourquoi. Peut-être que quelque chose est lié à la date .. Je ne sais pas. –

Tom,

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

Une cause fréquente de ce problème est de supprimer le répertoire sans "informer" SVN. Par exemple, si vous supprimez manuellement le répertoire en utilisant le système d'exploitation au lieu d'utiliser SVN, vous aurez ce problème.

Si vous avez supprimé le répertoire avant d'installer le plug-in subversion, mais que le projet existait déjà dans le référentiel, vous expérimenterez ce problème. Une solution, dans ce cas, serait de recréer le répertoire, en mettant à jour/commit, puis de supprimer à nouveau le répertoire.

Bonne chance.

Source

2010-05-10 19:07:21 luiscolorado

Je l'avais supprimé d'eclise. Cette Tortoise est une ligne de commande svn? Parce que cela fonctionne bien dans la ligne de commande, maintenant je veux que cela fonctionne dans la sous-clipse. –

Non, c'est un outil graphique qui s'intègre à Windows Explorer. C'est plutôt cool. Regardez sur http://tortoisesvn.tigris.org/. Télécharger et installer. Les instructions viennent dans un fichier d'aide de Windows, et sont assez claires. Si vous faites un clic droit sur un fichier ou un répertoire contrôlé par svn dans Windows Explorer, vous remarquerez des options telles que extraction, nettoyage, mise à jour, etc. Subclipse et Tortoise sont des interfaces visuelles pour SVN. Subclipse est dans Eclipse et Tortoise dans Windows. Subclipse a quelques bugs, bug je pense que Tortoise est plus fiable. En cas de problème, fermez Eclipse et utilisez Tortoise. – luiscolorado

N'est-il pas adressé par le Subclipse FAQ?

Chaque fois que vous voyez « démodés » dans un message d'erreur, il signifie que la révision de l'élément dans le référentiel est plus récent que la copie dans votre copie de travail locale.
La solution sera toujours d'exécuter une mise à jour, afin que votre copie de travail est à jour avec le référentiel, puis recommencez la validation (en supposant que la mise à jour n'a pas généré de conflits).

Pour les fichiers, il est généralement assez facile de comprendre comment et pourquoi cela se produit.

Toutefois, Subversion versions également les dossiers, et c'est généralement avec les dossiers que ce problème se produit le plus souvent.
Subversion ne vous permet pas de supprimer/renommer un dossier OU de modifier ses propriétés versionnées, SAUF si la copie locale du dossier est à la révision HEAD du dossier dans le référentiel.

Votre prochaine question pourrait être:
« OK, je peux peut-être comprendre, mais pourquoi est-mon dossier de ce jour, je suis la seule personne qui travaille dans ce référentiel?. "

C'est une question valable, la réponse réside dans la façon dont fonctionne Subversion.
Lorsque vous vous engagez un changement dans un fichier, la révision du fichier dans votre copie de travail est mis à jour à cette nouvelle révision lorsque le commit se termine, mais la version du ou des dossiers parents de ce fichier n'est pas mise à jour
En effet, il peut y avoir eu des ajouts/suppressions à d'autres fichiers dans ce dossier et jusqu'à ce que vous ayez exécuté une mise à jour, le dossier n'est pas vraiment à cette nouvelle révision.
Ceci est appelé "mixed revision working copies".

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

A propos de « mixtes Révision Copies de travail »:

Un type particulier de flexibilité est la possibilité d'avoir une copie de travail contenant des fichiers et des répertoires avec un mélange de différents numéros de révision de travail . L'une des règles fondamentales de Subversion est qu'une action "push" ne provoque pas de "pull", et vice versa. Ce n'est pas parce que vous êtes prêt à soumettre de nouvelles modifications au référentiel que vous êtes prêt à recevoir des modifications d'autres personnes.

Le fait est, chaque fois que vous exécutez svn commit votre copie de travail se termine avec un mélange de révisions.
Les choses que vous venez de commettre sont marquées comme ayant des révisions de travail plus importantes que tout le reste. Après plusieurs commits (sans mise à jour entre les deux), votre copie de travail contiendra tout un mélange de révisions

(et qui est la raison pour laquelle, je crois, vous ne pouvez pas reproduire votre message « à jour » sur commits ultérieures avec dossier supprimé:. votre mise à jour ne résout la « révision mixte » état)

révisions mixtes ont des limites

Vous ne pouvez pas commettre la suppression d'un fichier ou un répertoire qui ne sont pas entièrement à 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 les modifications que vous n'avez pas encore vues.

Source

2010-05-20 20:42:32 VonC

ok, mais comme déjà commenté dans la réponse similaire de praksant, faire une mise à jour ne fonctionne pas pour moi. –

@Tom là rien à mettre à jour maintenant. mais à un moment donné, ils doivent avoir une révision mixte, qui peut avoir résolu lui-même à travers la ligne de commande. Et maintenant vous ne pouvez pas reproduire le problème. Parce qu'il n'y a plus de révisions mixtes. – VonC

Je ne pouvais pas reproduire quand je le voulais, mais en ce moment j'avais supprimé un fichier et un répertoire, validé le fichier, et le répertoire ne peut pas être validé, comme un échec se produire. Et je ne peux pas mettre à jour (les boutons de mise à jour sont désactivés car il n'y a pas de mise à jour à faire, même si je me re-synchronise). Donc le conseil de mise à jour ne m'aide pas. La seule solution de contournement reste l'utilisation de la ligne de commande svn. Ressemble à un bogue non reconnu par Subclipse. –

La seule façon de travailler dans les mêmes cas est via une ligne de commande. La sous-claquette n'est toujours pas parfaite.

Source

2010-07-29 13:08:16

Ma solution à c'était

Supprimer tous les éléments dans le dossier
Engagez au référentiel
dossier de mise à jour à la tête
Supprimer dossier dans Eclipse
Commit au référentiel

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

Source

2011-02-22 20:39:30

Il y a une solution simple sans installer des fonctionnalités supplémentaires Logiciel. J'ai aussi eu ce « problème » et ce que vous pouvez faire est la suivante:

1) ouvrir la vue Repository SVN 2) y aller dans le dossier que vous voulez vous débarrasser et supprimer 3) revenir à la vue java 4) mettre à jour le dossier dans votre projet que vous avez réellement supprimé/mettre à jour votre projet devrait également travailler

qui a résolu le problème dans mon cas, que la mise à jour ne récupérer les fichiers supprimés figurent

Source

2011-07-13 11:13:38 Martin

svn: article <folder> est obsolète

Répondre

Questions connexes