Je me développe sur OSX et l'une de mes copies de travail de Subversion a commencé à renvoyer l'erreur suivante pour toutes les commandes, mais mes autres contrôles fonctionnent bien. Je reçois le même message avec mes fichiers binaires SVN installés ainsi que mon client de la pierre angulaire, mais d'autres répertoires de travail vont bien.
> ./bump-to-19.py working_directory/ error: format is 29 not 18: 'working_directory/'
4 Réponses :
Bien que je n'ai pas pu comprendre pourquoi mon répertoire de travail a été corrompu, j'ai pu contourner-y à l'aide de rsync - il existe une option, c , que Ignorera les fichiers et les répertoires CVS / SVN lors de la sauvegarde. J'ai fait une sauvegarde en utilisant cette option, vérifiée à nouveau le projet, puis copié la sauvegarde sur le nouveau répertoire de travail. Svn est encore heureux.
Solution soignée, mais je pense que celui-ci posté par User1794106 est plus facile et plus propre.
J'ai eu le même problème et voici comment j'ai résolu:
J'ai eu un problème similaire, ma SVN est la version 1.7.10, mais mon plugin de subversion pour Eclipse est légèrement plus âgé, je suppose 1,6.Quelque chose.
Utilisation de la commande "rsync -arc -arc working_directory archive_no_svn" était une percée - au moins maintenant, j'avais une copie des heures de synchronisation que je venais de terminer.
J'ai essayé d'utiliser le "SVN CO", mais c'était la mauvaise version, alors je faisais simplement une mise à jour à l'aide du plug-in Subversion dans Eclipse - cela a rétabli le répertoire de travail du référentiel - à peu près ce que j'étais après, et c'était la version correcte.
Retour à l'emplacement correct est un tour. RSYNC semble déposer le dossier de travail dans l'emplacement des archives, créant l'archive_location / Working_Directory / the-Files. Donc, la synchronisation des données archivées dans la diffusion de Working_Directory a été obtenue avec: rsync -ar archive_no_svn / working_directory.
Maintenant, je dois savoir la mise à niveau de mon plugin Subversion pour Eclipse sur 1.7
Je sais que cela fait environ un moment, mais j'ai trouvé une solution à l'aide des astuces données par SVN ... Utilisez essentiellement la commande de mise à niveau comme indiqué que cela. En utilisant cmd, je suis allé dans mon dossier d'espace de travail où le projet troublé était situé. Permet d'appeler le projet de projet1. Vous appelez la commande:
"Projet de mise à niveau SVN1"
Cela résolut mon problème la manière appropriée sans impliquer une sorte de piratage ou de contournement.
Merci beaucoup! Cela a fonctionné comme un charme. Je dois noter que le projet CD1; SVN Upgrade , que j'ai initialement essayé, ne fonctionne pas.
Je voulais juste ajouter une note sur votre réponse que je a fait Essayez d'exécuter SVN Upgrade Project_Name mais obtient le même message d'erreur que les autres commandes SVN. Vaut certainement la peine d'essayer d'abord cette option, beaucoup plus propre si cela fonctionne.