Falsche Subversion-Binärdateien in /bin /usr/bin

Falsche Subversion-Binärdateien in /bin /usr/bin

Ich arbeite auf einem Mac und habe Xcode kürzlich aktualisiert. In diesem Update wird die neueste Version subversion 1.9.xals Kerninstallation installiert. Das wäre in Ordnung, aber bei der Arbeit verwenden wir 1.8.xund diese neuere Version ist inkompatibel.

Idealerweise würde ich die Core-Subversion gerne wieder auf 1.8.x ändern, bin mir aber nicht sicher, wie ich weiter vorgehen soll. Was ich bisher getan habe, ist, die richtige Version über den Paketmanager (Homebrew) in zu installieren /usr/local/opt/subversion.

Für meine IDE ist das in Ordnung, da ich auf den Ordner ./bin verweisen kann. Wenn ich jedoch im Terminal arbeiten möchte, was ich häufig tue, ist die Version 1.9.x.

Als Workaround habe ich in meinem ./bash_profilewie folgt einen Alias ​​erstellt .alias svn=/usr/local/opt/[email protected]/bin/svn

Wenn ich jetzt das Terminal öffne und ausführe, svn --versionerhalte ich Folgendes.

svn, version 1.8.16 (r1740329) compiled Apr 2 2017, 22:11:27 on x86_64-apple-darwin15.6.0

Das ist perfekt, aber ich habe das Gefühl, dass mir etwas fehlt. Es gibt dort andere Binärdateien, die ich von Zeit zu Zeit verwende, und ich möchte sie nicht alle mit Aliasnamen versehen. Es scheint, als gäbe es einen besseren Weg, aber ich bin nicht so sicher, wie ich Dinge auf Stammebene verschieben soll.

Ist es möglich, die Arbeitsversion von Subversion neu zuzuweisen? Vielleicht so etwas wie use svn --path ....

Antwort1

Beim Bearbeiten $PATHkönnen Sie die Umgebungsvariable anhängen, um die bevorzugte Reihenfolge der zu verwendenden Binärdateien festzulegen. Dies ist möglicherweise nicht unbedingt erforderlich.

Wenn Sie svn upvom Terminal aus eine Arbeitskopie mit einer nicht übereinstimmenden Subversion ausführen, erhalten Sie die folgende Meldung.

svn: E155036: Please see the 'svn upgrade' command

Meine Erfahrungen mit dem blinden Ausführen von Befehlen in der Vergangenheit machen mich nervös, aber nachdem ich die Rechner mehrerer Kollegen untersucht habe, ist klar, dass die Inkompatibilität bei der Arbeitskopie und nicht beim VCS-Server liegt.

Um die Nichtübereinstimmung zu beheben, können Sie einfach ausführen svn upgrade. Danach können Sie ausführen svn upund das Update sollte problemlos fortgesetzt werden.

svnWenn alles andere fehlschlägt, können Sie immer noch die Verwendung einer bestimmten Version der Binärdatei erzwingen, indem Sie in der $PATHUmgebungsvariable den Pfad zu Ihrem Subversion-Ordner festlegen.

z.Bexport PATH=/usr/local/opt/[email protected]/bin:/usr/bin:/bin:$PATH

Was ich mir bisher nicht wirklich die Zeit genommen habe zu verstehen, ist, dass es $PATHden Speicherort aller Binärdateien enthält, auf die Sie über die Befehlszeile zugreifen möchten. Je weiter vorne in der Zeichenfolge die Binärdatei Ihrer Wahl steht, desto mehr wird die Reihenfolge bestimmt, in der sie ausgewählt werden.

Wenn ein Ordner nicht mehr verfügbar ist, sollte er meiner Meinung nach an den nächsten Speicherort weitergeleitet werden.

verwandte Informationen