Subversion: Arbeitskopie ist eine alte Entwicklungsversion

8

Ich entwickle unter OSX, und eine meiner Subversion-Arbeitskopien hat gerade angefangen, den folgenden Fehler für alle Befehle zurückzusenden, aber meine anderen Checkouts funktionieren gut. Ich bekomme die gleiche Nachricht sowohl mit meinen installierten SVN-Binärdateien als auch mit meinem Cornerstone-Client, aber andere Arbeitsverzeichnisse sind in Ordnung.

%Vor%

Ich habe das bump-to-19.py -Skript nirgendwo auf meinem Computer (nach find / -type f -name bump-to-19.py ), aber ich glaube, ich konnte es auf der Apache-Repository . Das heißt, ich bin nicht vertraut mit dem, was es tut, oder wie man es benutzt. Im Idealfall kann ich es vermeiden, eine neue Version dieses Arbeitsverzeichnisses auszuprobieren und alle meine (vielen) Änderungen manuell zusammenzuführen.

Die einzige Information, die ich finden konnte, ist verwandt mit Netbeans und javahl , und ich bin Verwenden Sie keine.

BEARBEITEN : Nachdem ich die bump-to-19.py -Datei heruntergeladen und ausführbar gemacht habe, habe ich sie vergeblich gegen mein Arbeitsverzeichnis ausprobiert:

%Vor%     
doublesharp 06.11.2012, 23:18
quelle

4 Antworten

12

Obwohl ich nicht herausfinden konnte, warum mein Arbeitsverzeichnis beschädigt war, konnte ich es mit rsync umgehen - es gibt eine Option, C , die CVS / SVN-Dateien und Verzeichnisse ignoriert, wenn sie erstellt wird eine Sicherung. Ich habe mit dieser Option ein Backup erstellt, das Projekt erneut ausgecheckt und dann das Backup über das neue Arbeitsverzeichnis kopiert. SVN ist wieder glücklich.

%Vor%     
doublesharp 07.11.2012, 01:10
quelle
8

Ich hatte das gleiche Problem und hier ist, wie ich gelöst habe:

  1. Löschen Sie den .svn-Ordner auf der obersten Ebene (rm -rf .svn)
  2. Software erneut von SVN (svn co ...) herunterladen
  3. Gut zu gehen!
Mike 08.05.2013 13:40
quelle
5

Ich weiß, dass es schon eine Weile her ist, aber ich habe eine Lösung gefunden, die die Hinweise von SVN verwendet ... Grundsätzlich benutze den Upgrade-Befehl, wie er sagt. Mit CMD ging ich in meinen Arbeitsbereichordner, in dem sich das problematische Projekt befand. Rufen wir das Projekt Project1 auf. Sie rufen den Befehl auf:

"svn upgrade project1"

Dies hat mein Problem auf die richtige Art und Weise gelöst, ohne irgendeine Art von Hack oder Workaround einzubeziehen.

    
eaglei22 03.09.2014 15:50
quelle
0

Ich hatte ein ähnliches Problem, mein SVN ist Version 1.7.10, aber mein Subversion-Plugin für Eclipse ist etwas älter, ich gehe von 1.6.etwas.

Der Befehl "rsync -arC working_directory archive_no_svn" war ein Durchbruch - zumindest hatte ich jetzt eine Kopie der Stunden der Synchronisation, die ich gerade beendet hatte.

Ich habe versucht, die "svn co" zu verwenden, aber es war die falsche Version, also habe ich einfach ein Update mit dem Subversion-Plugin in Eclipse ausgeführt - das hat das Arbeitsverzeichnis aus dem Repository wiederhergestellt - ziemlich genau das, wonach ich gesucht hatte die richtige Version.

Es war ein Trick, das rsync zurück an den richtigen Ort zu bringen. rsync scheint den Arbeitsordner an den Speicherort des Archivs zu legen und erstellt archive_location / working_directory / the-files. Die Synchronisierung der archivierten Daten in das working_directory wurde erreicht mit: rsync -ar archive_no_svn / Arbeitsverzeichnis.

Jetzt muss ich herausfinden, wie ich mein Subversion-Plugin für Eclipse auf 1.7 upgraden kann

    
muz the axe 13.03.2014 12:10
quelle

Tags und Links