2010-05-27 4 views
10

Ich benutze git-svn. Ich habe die Datei 'A' nach 'B' verschoben und bin auf dem neuesten Stand mit dem SVN HEAD (mit git svn rebase). Ich kann alle anderen Änderungen ohne Probleme vornehmen. Jetzt habe ich entschieden, dass ich "B" zurück zu "A" bewegen und diese Änderung begehen will.Wie man von einem unerwünschten Umbenennen mit git-svn wiederherstellen: "Die Transaktion ist veraltet"

Als ich tun, um die Bewegung und verpflichten zu meinem lokalen Master es funktioniert gut, aber ich habe folgendes zu tun ein git svn dcommit:

Transaction is out of date: Out of date: 'A' in transaction '3652-1' at /opt/local/libexec/git-core/git-svn line 570 

Also habe ich versucht, in einem separaten zu kopieren und löschen verpflichten, die in Folge :

Item already exists in filesystem: File already exists: filesystem '/usr/svn/db', transaction '3652-1', path 'A' at /opt/local/libexec/git-core/git-svn line 4735 

ich habe mithilfe der Abhilfen wie die in den documentation beschrieben ein svn mit glattem aus dieser Situation erholt, aber ich weiß nicht, wie mit git-svn zu erholen. Was ist los und wie repariere ich es?

Antwort

6

Das Entfernen von .git/svn funktionierte nicht für mich. Stattdessen ist hier, wie ich beschlossen:

  • die beanstandeten Verzeichnisse aus dem Repository gelöscht
  • git svn rebase
  • (Aber ich bin nicht sicher, dass dies notwendig ist, im Nachhinein denke ich, dass ich diesen Schritt übersprungen haben könnte.) Während der Rebase gab es einige Konflikte. Für jeden Konflikt löste ich die Konflikte im Text-Editor, dann git add <file-in-conflict> und dann
  • Nach Rebase erfolgreich abgeschlossen, git svn dcommit lief erfolgreich!
+0

finden kann Kann jemand bestätigen, dass dies funktioniert (auch)? Es scheint, als hätte es einen Downvote, aber ich weiß nicht warum. – iwein

+1

@iwein: Dieser arbeitete für mich und die angenommene Antwort nicht. –

+1

Das funktionierte auch für mich, und ich brauchte keinen ersten Schritt (Löschen von anstößigen Verzeichnissen). –

4

Ich kann nicht behaupten zu verstehen, was wirklich unter der Haube in git-svn in diesem Fall vorgeht (obwohl das zugrundeliegende SVN Problem vollkommen sinnvoll ist). Meine übliche Strategie, wenn git-svn irgendwie verwirrt wird, ist, das Metadatenverzeichnis .git/svn wegzublasen (wie in this post). Das rettet mich fast immer vor seltsamen Synchronisationsproblemen zwischen den Git- und SVN-Repositories.

+0

Danke für die Eingabe. Könntest du ein wenig darüber erzählen, wie die SVN-Frage vollkommen Sinn macht? Ich werde versuchen, es zu reproduzieren und zu sehen, ob das .git/svn-Verzeichnis wegbläst. Ich erinnere mich vage daran, dass ich tatsächlich einen frischen Klon gemacht habe und das Problem immer noch da war. – iwein

+0

Es sieht aus wie ein Problem einer "gemischten Revision" Arbeitskopie, wo ein Teil der Arbeitskopie auf eine andere, ältere Revision als der Rest der WC aktualisiert wurde. Aber ich kann nicht wirklich sagen, welche Teile veraltet sind. Dies wird teilweise hier beschrieben: http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.basic.in-action.mixedrevs. Hat der Trick zum Entfernen von Metadaten für Sie funktioniert? –

+0

Ich konnte es aufgrund der Volatilität meiner lokalen Codebasen nicht mehr testen.Nehmen wir an, dass es funktioniert, bis jemand findet, dass es nicht :) – iwein

0

Es passierte mit mir, als ich den dcommit Prozess unterbrach.

Führen Sie die folgenden Schritte aus Fehler zu beheben:

  1. git svn rebase
  2. Sie werden in Dateien erhalten Konflikte. Beheben Sie die Konflikte & dann git add filename (in dem Konflikt aufgetreten ist) für jede Datei.
  3. Jetzt tun Sie git svn dcommit. Es wird erfolgreich an die Remote-Position übertragen.
+0

Interessantes Detail. Aber das Rezept ist das gleiche wie die angenommene Antwort. – iwein