Problème étrange avec Subversion – “Le fichier existe déjà” lorsque vous essayez de recréer un répertoire qui a servi à être dans mon référentiel

Donc, j’avais un répertoire appelé mysql il ya quelques révisions. Je l’ai supprimé et j’ai décidé de recommencer – mais lorsque j’essaie de créer le nouveau répertoire mysql – je continue à courir dans l’erreur “Fichier déjà existant”:

support:/etc/puppet/modules# mkdir mysql support:/etc/puppet/modules# svn add mysql/ A mysql support:/etc/puppet/modules# svn commit -m " Test" Adding modules/mysql svn: Commit failed (details follow): svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-r', path '/trunk/modules/mysql' support:/etc/puppet/modules# svn delete mysql svn: Use --force to override this ressortingction svn: 'mysql' has local modifications support:/etc/puppet/modules# svn --force delete mysql D mysql 

J’ai vu d’autres articles suggérer de forcer une mise à jour

 support:/etc/puppet/modules# svn status support:/etc/puppet/modules# svn update At revision 11. support:/etc/puppet/modules# svn mkdir mysql A mysql support:/etc/puppet/modules# svn commit -m "Test" Adding modules/mysql svn: Commit failed (details follow): svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-s', path '/trunk/modules/mysql' 

J’ai eu un problème comme celui-ci lorsque j’ai supprimé un dossier (et des sous-dossiers) et que je suis allé les recréer à partir de zéro . Vous obtenez cette erreur en supprimant et en rajoutant manuellement des dossiers (alors que les fichiers semblent fonctionner correctement avec ceci).

Après quelques déconvenues frustrantes, j’ai constaté que je devais:
(en utilisant TortoiseSVN sous Windows)

  1. Déplacer les dossiers en conflit de la copie de travail (pour ne pas perdre mon travail en cours)
  2. Faites une svn update qui a ajouté d’anciens fichiers / dossiers à la copie de travail
  3. svn delete dossier
  4. commit
  5. Copiez le nouveau dossier dans la copie de travail (en vous assurant de supprimer tous les dossiers .svn à l’intérieur)
  6. commit

Malheureusement (A) nécessite deux commits et (B) perd l’historique de révision des fichiers car il ne fait que remonter au rajout récent (sauf si quelqu’un peut expliquer comment résoudre ce problème). Une solution alternative qui fonctionne autour de ces deux problèmes consiste à ignorer les étapes 3 et 4 , le seul problème étant que les fichiers anciens / inutiles peuvent toujours être présents dans votre répertoire. Vous pouvez les supprimer manuellement.

Aimerait entendre des idées supplémentaires que d’autres pourraient avoir à ce sujet.

Simon.


[Mise à jour] OK, j’ai eu à nouveau le même problème à ce moment-là, mais le dossier incriminé n’était PAS dans le dernier commit, donc une update ne l’a pas restaurée. Au lieu de cela, j’ai dû parcourir le référentiel et delete le dossier incriminé . Je pourrais alors add le dossier et le commit avec succès.

Avait un problème similaire. Pour le résoudre, mise à jour depuis svn trunk avec option de priorité des fichiers locaux.

 svn update path/ --accept=mine-full 

Après Vous pouvez vous engager comme d’habitude. Bien sûr, soyez prudent en l’utilisant.

déjà eu ce type de problème.

ma solution était:

Supprimez le dossier de svn mais conservez une copie du dossier quelque part, validez les modifications. dans la copie de sauvegarde, supprimez récursivement tous les dossiers .svn. pour cela vous pourriez courir

 #!/bin/bash find -name '.svn' | while read directory; do echo $directory; rm -rf "$directory"; done; 

Supprimez le référentiel local et réexaminez tout le projet. Je ne sais pas si une suppression / vérification partielle est suffisante.

Cordialement

J’ai réussi à contourner ce problème en revenant à la dernière version contenant le répertoire mysql, puis en supprimant le contenu du répertoire, en y insérant le nouveau contenu et en vérifiant les nouvelles informations. tout le monde a une meilleure explication de ce qui se passait là-bas.

Ceci est une méchante erreur mystérieuse et aucun correctif clair.

update / revert / commit n’a pas fonctionné dans ma situation. Je n’avais rien fait de bizarre – juste quelques mouvements svn.

Qu’est-ce que DID travail pour moi était:

 svn remove offender svn commit cd .. rm -fR parent svn up parent cd parent svn remove offender again svn commit copy offender back in (minus .svn dirs) svn add svn commit 

Bizarre pour le moins. Fondamentalement, le svn remove --force offender ne supprimait pas complètement pour une raison quelconque. Ce qui est en quelque sorte ce que le message d’erreur disait. Ce n’est qu’en enlevant le parent, puis en mettant à jour le parent, que cela est devenu évident parce que le délinquant a réapparu! svn retirer à nouveau le délinquant, puis le retirer correctement.

Je ne suis pas sûr que cela vous aide, mais je suppose que lorsque vous faites un svn add mysql après l’avoir supprimé, il ne fera que rétablir le répertoire (donc ne faites pas vous-même un mkdir). Si vous créez vous-même un répertoire, svn attend un répertoire .svn car il le sait déjà.

  1. renommer le nouveau chemin d’access à temp
  2. retourne le nouveau chemin (pas temp!) donc svn n’essaye pas de le valider
  3. engager le rest de vos changements
  4. copier le chemin dans le repository: svn copy -m “chemin copié” -r
  5. mettre à jour votre copie de travail
  6. mv tous les fichiers de temp au nouveau chemin, qui provient de la mise à jour
  7. validez vos modifications locales depuis la révision
  8. Bonne journée, y compris l’histoire 😉

J’ai eu ce problème sur un projet que je lance sur Netbeans. J’ai simplement cliqué sur le fichier et mis à jour pour le réparer (après SVN).

Cette solution se fond parfaitement et ne perd pas l’histoire:

  1. Déplacer / copier-travailler / délinquant vers un emplacement temporaire.
  2. Faites un svn checkout de svn + ssh: //svn.example.com/repo/offender vers / working-copy / offender.
  3. Déplacez manuellement vos fichiers de l’emplacement temporaire dans la nouvelle extraction.
  4. Supprimez l’emplacement temporaire.

J’ai rencontré ce problème aujourd’hui lorsque Xcode est tombé en panne lors d’une fusion de twig. D’une manière ou d’une autre, le fichier a été téléchargé dans le référentiel svn mais il n’a pas été enregistré correctement dans la firebase database svn. J’ai exécuté les commandes suivantes dans le répertoire où le fichier existait localement:

 svn revert bad.file svn del svn://my.svnserver.com/svnDB/path/to/the/offending/file/bad.file 

Puis j’ai rajouté le fichier de mon système local:

 svn add bad.file svn commit -m "Re adding bad.file" 

Succès!

Cette situation s’est produite s’il y a un object dans le référentiel, qui crée par transaction en cours.

Scénario simple:

  1. extraire un répertoire deux fois, comme DIR1 et DIR2
  2. faire ‘svn mkdir test’ dans les deux
  3. make commit de DIR1
  4. essayer de faire commettre DIR2 (sans svn up), SVN doit renvoyer cette erreur

Même chose en ajoutant les mêmes fichiers à partir de deux copies de travail.

Conformément à la solution Atmocreation, sauf que vous n’avez pas besoin de revérifier l’ensemble du projet, ce qui est utile si vous avez déjà des travaux en cours.

Disons que vous avez une copie de travail:

 /foo/ 

qui contient des répertoires:

 /foo/bar/baz 

et vous obtenez le message d’erreur sur commit:

 svn: File already exists: filesystem '/foo/bar' 

Sauvegardez le contenu de la barre quelque part:

 mkdir -p ~/tmp/code_backup cp -r /foo/bar ~/tmp/code_backup 

Supprimez les répertoires de contrôle .svn de la sauvegarde. Assurez-vous que cette commande est correcte ou que vous pouvez faire des dégâts assez sérieux !! Supprimez-les manuellement si vous n’êtes pas sûr.

 find ~/tmp/code_backup/bar -name .svn -type d -exec rm -rf {} \; 

Vérifiez que la copie est identique:

 diff -r -x .svn dist ~/tmp/code_backup/dist 

Supprimez le répertoire incriminé de la copie de travail: cd / foo rm -rf bar

Et puis le restaurer à partir du référentiel:

 cd /foo svn update bar 

Recopiez les fichiers modifiés à partir de la sauvegarde:

 cp -r ~/tmp/code_backup/bar /foo/ 

Vous devriez maintenant pouvoir vous engager sans erreur.

Vous avez besoin de la commande svn ‘export’. Avec cela, vous pouvez mettre un fichier ou une arborescence complète dans l’état d’une autre révision dans une autre twig.

Donc quelque chose comme

 rm file #without 'svn' in front! svn export myrepo/path/to/file@ . svn commit 

Le problème est que la vérification a lieu sur un ordinateur portable et dans ce cas, la subversion ne peut pas faire face à la synchronisation hors ligne. Le problème est reproductible sur un autre ordinateur portable alors que sur un ordinateur de bureau, je n’ai aucun problème à vérifier le même référentiel.

J’espère que cette réponse vous aidera, cela m’a pris beaucoup de temps pour le savoir.