Comment corriger l'erreur "Echec de la validation. Le fichier xxx est obsolète. Le chemin xxx est introuvable."
Je suis récemment tombé sur une question particulièrement délicate concernant le résultat d'une fusion avec Subversion. Notre serveur Subversion est @ 1.5.0 et mon client TortoiseSVN est maintenant @ 1.6.1.
J'essaie de fusionner une branche de fonctionnalité dans mon coffre. La fusion semble fonctionner correctement; toutefois, la validation échoue avec le message d'erreur suivant.
Commit failed (details follow):
File
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as'
is out of date
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as'
path not found
You have to update your working copy first.
Ma malle de travail est à jour. J’en ai même jeté un nouveau dans un autre dossier pour s’assurer qu’il n’y avait aucune foutaise au niveau local avec la fusion. J'ai fait quelques recherches supplémentaires à ce sujet et je pense qu'une partie du problème est l'erreur de l'utilisateur. Je pense que nos problèmes sont:
- Certains développeurs ont déjà travaillé avec un client Subversion avant la version 1.5 et d'autres après. Je crois que cela a le potentiel de corrompre les informations de fusion.
- Dans d'autres branches, nous avons effectué des fusions partielles. C'est-à-dire que nous n'avons pas toujours effectué des fusions à la racine de la branche. Cela visait à faciliter la mise à jour des efforts Flex et .NET au sein de la même branche.
- Nous avons effectué des fusions (réflexives) cycliques sur notre branche. Cela a été fait parce que nous avions plusieurs branches parallèles et que nous voulions mettre à jour périodiquement notre branche avec le dernier code dans le coffre.
Toutes ces choses ne sont explicitement pas recommandées par le livre/l'équipe de Subversion. Nous avons appris notre leçon et connaissons maintenant les meilleures pratiques. Cependant, nous devons d’abord fusionner et engager notre dernière branche.
Quelle est la meilleure façon de corriger les problèmes que nous rencontrons?
La suppression de toutes les informations de fusion dans le tronc et la branche serait-elle une solution viable? Non. Je l’ai fait mais cela ne résout pas l’erreur que j’obtiens ci-dessus.
J'ai le même problème aujourd'hui et je n'ai pas fait de fusion intermédiaire. Par conséquent, à partir de votre message d'ouverture, seul le n ° 1 est susceptible d'être appliqué. Heureusement, dans mon cas, aucune modification n'a été apportée au coffre afin que je puisse simplement remplacer le coffre par la branche. Peut-être différentes versions de svn alors? C'est assez inquiétant.
Si vous utilisez les fonctions svn move/copy/delete bien qu'aucun historique ne soit perdu dans mon cas, i svn a déplacé le tronc, puis svn a déplacé la branche vers le tronc.
Je viens d'avoir ce problème, et la cause semblait être qu'un répertoire avait été marqué comme étant en conflit. Pour réparer:
svn update
svn resolved <the directory in conflict>
svn commit
Je recevais cela sur le serveur 1.6.2, 1.6.8 tortue. Tout sur Windows, aucune fusion dans cette branche.
J'ai renommé un répertoire et d'une manière ou d'une autre (probablement à cause d'AnkhSVN) deux des fichiers du répertoire étaient marqués comme "remplacés" plutôt que "normaux". Des modifications mineures supplémentaires ont été apportées à d'autres fichiers du répertoire.
La restauration des fichiers marqués comme remplacés a résolu le problème.
J'ai également eu le même problème et j'ai résolu le même par la méthode suivante
svn resolve --accept=working <FILE/FOLDER NAME>
svn cleanup
svn update <FILE/FOLDER NAME>
svn commit <FILE/FOLDER NAME> -m "Comment"
J'espère que ceci vous aidera :)
J'ai eu le même problème en essayant de valider ma copie de travail. Ce que j’ai fait, c’est d’ajouter le dossier indiqué par Subversion comme "chemin non trouvé" à la liste des ignorés. S'engager (devrait réussir). Ajoutez ensuite le même dossier à Subversion. S'engager à nouveau.
Je viens d'avoir un problème similaire, mais sans aucune branche ou fusion pour causer le problème. Ma solution de contournement était de:
- svn exporte mon dossier de travail (y compris les fichiers non versionnés) dans un dossier temporaire.
- renommer le dossier de travail une sauvegarde.
- svn checkout le coffre.
- copier tout le dossier du dossier d'exportation temporaire sur le nouveau dossier de travail.
- svn commit.
Tout semble bien maintenant.
Je sais que ceci est un ancien post, mais ce problème se pose encore assez fréquemment. Le moyen le plus simple que j'ai trouvé pour le résoudre consiste à renommer/supprimer le fichier .svn/all-wcprops dans le dossier concerné, puis à exécuter une mise à jour et une validation.
J'ai été incapable de trouver une solution satisfaisante à ce problème. Cependant, j'ai trouvé une solution peu satisfaisante.
J'ai supprimé tous les fichiers dans le coffre et validé ces modifications. J'ai ensuite exporté mon code de branche dans le coffre, ajouté tous les fichiers et effectué une validation importante. Cela a eu l'effet de ma trompe imitant ma branche 1: 1 (qui est ce que je voulais de toute façon).
Malheureusement, cela crée un grand fossé car l'historique de tous les fichiers est maintenant "perdu". Mais en raison de contraintes de temps, il ne semblait pas y avoir d’autre option.
Je serai toujours intéressé par toutes les réponses que d'autres pourraient avoir car je voudrais savoir quelle était la cause première et comment l'éviter à l'avenir.
Avait un problème similaire avec le SVN 1.6.5 sur Mac 10.6.5, mis à niveau vers SVN 1.6.9 et la validation a réussi.
J'ai eu le même problème après avoir fusionné une branche avec une tonne de modifications dans mon coffre. Les deux seules solutions possibles étaient de faire la solution svn move proposée par Pacifika ou de fusionner manuellement les fichiers avec un outil de comparaison. Mais j'ai trouvé une solution de contournement ...
La machine qui ne fonctionnait pas exécutait le client Subversion 1.6.5. J'ai fait exactement la même chose sur une machine avec Subversion 1.5.4 et cela a fonctionné! Sur les deux machines, j'ai effectué 1) un nettoyage complet du coffre, 2) svn merge ... et 3) svn commit. Mon serveur est 1.5.x pour ce que ça vaut.
J'espère que ça aide quelqu'un.
J'ai eu le même problème, je ne sais pas quelle est la raison derrière, mais j'ai résolu en tapant dans le terminal
svn update
et puis je me suis engagé et ça a fonctionné!
Oh mec! Cela semble mauvais! La seule option à laquelle je peux penser est que la copie de travail est corrompue.
Essayez de supprimer la copie de travail, d'effectuer une nouvelle extraction et d'effectuer à nouveau la fusion.
Si cela ne fonctionne pas, alors enregistrez un bogue.
J'ai eu le même problème lorsque j'ai essayé de valider un package supprimé (qui contient diverses classes Java mais que rien du package n'était plus nécessaire).
Ma solution/solution de contournement afin de résoudre le problème:
- J'ai retourné tout le paquet
- supprimé le contenu en premier
- commité le contenu supprimé
- enfin, j'ai à nouveau validé le paquet supprimé (et cela a fonctionné dans la plupart des cas :-))
Cependant, de temps en temps, il n'était pas possible de valider un package supprimé (qui ne contient rien)
Ma solution de contournement:
- J'ai créé une classe factice dans le package
- et après que j'ai répété les étapes mentionnées ci-dessus
Mon dernier indice ...
Mais il est parfois utile de synchroniser une fois de plus le paquet/projet et ensuite tout fonctionne à nouveau correctement.
À propos de ma configuration:
- Eclipse Neon
- Interface SVN: JavaHL (JNI) 1.8.13 (r1667537)
- Gestionnaire de serveur VisualSVN, Version: 3.3.1
Peut-être que je pourrais aider quelqu'un avec l'un de mes conseils.
Wow, celui-ci m'a pris un certain temps à résoudre, car j'utilisais SVN via Eclipse. En fin de compte, la seule chose qui a fonctionné pour moi a été de valider tous les fichiers non affectés, puis (avec Eclipse fermé) de renommer le répertoire du projet et de re-extraire le projet à partir de SVN. Heureux que cela fonctionne correctement maintenant!
Je pense avoir vu quelque chose de similaire lorsque des dossiers ont été déplacés sur le serveur mais que les copies de travail étaient toujours liées à l'ancienne structure de dossiers SVN. Je ne sais pas si quelqu'un a déplacé des objets dans votre coffre avant que vous ayez pu fusionner la branche.
Est-ce une possibilité?
J'ai rencontré le même problème, me suis cogné la tête et découvert que j'avais changé le répertoire dans le répertoire "/" de "/" en "/ coffre" et que j'avais oublié de faire la commande "Switch", dans TortoiseSVN!
Merci Jamie Bullock ce travail pour moi
Selon Jamie Bullock,
Je viens d'avoir ce problème, et la cause semblait être qu'un répertoire avait été marqué comme étant en conflit. Pour réparer:
- svn update
- svn résolu
- svn commit
J'en doute, mais peut-être qu'exécuter svn cleanup sur votre répertoire de travail vous aidera.
Apparemment, SVN n'est pas un programme très fiable. J'ai eu le même problème (en utilisant SVN avec Turtoise) et je l'ai résolu en enregistrant le contenu du fichier .cs, puis en remontant 1 révision. Cela montrait des conflits comme celui-ci: "<<<<<<< nom de fichier mes modifications
======= code fusionné du référentiel revision "
alors que je n'ai rien fait de spécial (juste une fois en arrière une révision).
J'ai remplacé le contenu de ce fichier par le contenu enregistré, enregistré puis sélectionné via TortoiseSVN → Résolu . Je pourrais ensuite valider les modifications dans le référentiel.
Cela ressemble à un problème lié à la sortie de la propriété svn:mergeinfo entre la branche et le tronc.
Ce qui conduit aux questions suivantes (pardonnez mes instructions en ligne de commande car j'ai beaucoup utilisé tortoise):
Êtes-vous en train de fusionner au niveau racine du coffre ou au niveau des sous-dossiers? D'après mon expérience, il est toujours préférable de le faire au niveau de la racine, de cette façon, le tronc entier pense qu'il a été fusionné au lieu d'une partie (cela semble confondre grandement svn dans 1.5.0)
Ma prochaine question est la suivante: utilisiez-vous le paramètre
--reintergrate? Je ne me souviens jamais comment arriver à cela en tortue, mais lorsque vous retournez dans le coffre depuis une branche, vous devez utiliser ce paramètre.Avez-vous fusionné le tronc dans la branche avant de vous réintégrer? Cela peut aider à éliminer les conflits que vous pouvez voir lorsque vous fusionnez?
Avez-vous des propriétés
svn:mergeinfosur la branche qui ne sont pas au niveau racine? J'ai trouvé que cela pose toujours des problèmes. Vous pouvez toujours le savoir en allantsvn -R pg svn:mergeinfo. Vous pouvez ensuite enregistrer les emplacements et les révisions situés sous la racine. Si vous les trouvez pertinents, déplacez-les vers la racine avecsvn merge --record-only -r start:end <location>, puis supprimez-les des emplacements de sous-racine avecsvn pd svn:mergeinfo <location>. Vous devez ensuite valider ces modifications.Une fois que tout est fait, essayez de fusionner à nouveau.