17 Stimmen

git-Klon des git-svn-Baums?

Ich habe einen 'git-svn'-Arbeitsbaum. Ich würde gerne ein "reines" Git-Repository aus diesem klonen und dann git push/pull verwenden, um Änderungen zwischen dem git-svn-Baum und dem Git-Baum zu verschieben, während ich auch "git svn dcommit/rebase" verwende, um Änderungen zwischen dem git-svn-Baum und dem SVN-Repository, auf dem er basiert, zu verschieben.

Dies scheint zu funktionieren okay so weit wie verschieben Dinge hin und her zwischen den Git-Bäume mit Git-Methoden, aber sobald ich mit dem SVN Repo in der Git-svn-Baum interagieren, Dinge bekommen wonky -- entweder bekomme ich Fehler, wenn Pushing oder Pulling zwischen den Git-Bäume, oder ich verliere Commits in der Git-svn-Baum, oder andere Seltsamkeit.

Wird diese Art von SVN <-> git-svn <-> git-Workflow überhaupt unterstützt, oder sollte ich einfach aufhören, diesen Baum zu erkunden?

10voto

Christoph Rüegg Punkte 4476

Ich habe für einige meiner Projekte eine Bridge eingerichtet, die aber nur eine Verbindung von Git zu SVN herstellt (einen öffentlichen, schreibgeschützten SVN-Spiegel unseres Git-Masterzweigs). Da es jedoch gut funktioniert, könnte es Ihnen helfen oder Sie in Ihrem Zwei-Wege-Szenario in die richtige Richtung weisen, da ich davon ausgehe, dass es git->svn ist, das Probleme macht, nicht svn->git:

Mein einseitiges Szenario: Vorhandenes Git-Repository auf Github, benötige einen schreibgeschützten svn-Spiegel des Git-Master-Branches

  • Erstellen und initialisieren Sie das Ziel-Subversion-Repository auf dem Server:

    svnadmin create svnrepo
    mkdir trunk
    svn import trunk svn://yoursvnserver/svnrepo
    rmdir -rf trunk
  • Erstellen eines gemischten Git-Svn-Checkouts und Initialisierung des Subversion-Repository

    git svn clone svn://yoursvnserver/svnrepo/trunk
    cd trunk
    git remote add github git://github.com/yourname/repo.git
    git fetch github
    git branch tmp $(cat .git/refs/remotes/github/master)
    git tag -a -m "Last fetch" last tmp
    INIT_COMMIT=$(git log tmp --pretty=format:%H | tail -1)
    git checkout $INIT_COMMIT .
    git commit -C $INIT_COMMIT
    git rebase master tmp
    git branch -M tmp master
    git svn dcommit --rmdir --find-copies-harder
  • Aktualisieren Sie den Spiegel

    git fetch github
    git branch tmp $(cat .git/refs/remotes/github/master)
    git tag -a -m "Last fetch" newlast tmp
    git rebase --onto master last tmp
    git branch -M tmp master
    git svn dcommit --rmdir --find-copies-harder
    mv .git/refs/tags/newlast .git/refs/tags/last

Diese beiden Artikel von googlecode könnten ebenfalls hilfreich sein:

0 Stimmen

Ich habe für diese Antwort gestimmt, da ich sie für allgemein nützlich halte, allerdings basiert sie auf einer fehlerhaften Prämisse. Das Problem ist mit ziemlicher Sicherheit nicht git->svn, noch svn->git, zumindest nicht direkt. Vielmehr wird der Schritt git-svn->git das Problem sein, da die Historie durch svn->git umgeschrieben wird, was bedeutet, dass die beiden Repositories nicht mehr die gleiche Historie haben und das Leben verwirrend wird.

9voto

araqnid Punkte 116680

Eine Sache, die Ihnen vielleicht Probleme bereitet, ist, dass git svn dcommit wird alle Commits, die es an SVN sendet, neu schreiben - zumindest, wenn es so konfiguriert ist, dass es die SVN-Metadaten am Ende der Commit-Nachrichten hinzufügt. Sie müssen also einen Ablauf einführen, bei dem alle Repositories, die Commits aus Ihrem git-svn-Arbeitsbereich übernehmen, gegen diesen rebasen und dabei die gesamte Merge-Historie verlieren, die ohnehin nicht in SVN gespeichert werden kann.

0 Stimmen

Gestimmt, da dies wahrscheinlich die eigentliche Ursache des Problems ist, zumindest nach meinem Verständnis des Problems.

5voto

genehack Punkte 126986

Nach dem, was ich gesehen habe, wird dieser Arbeitsablauf von git-svn nicht unterstützt und wird es auch nicht, aufgrund der Art und Weise, wie SVN Zusammenführungen darstellt.

0 Stimmen

Diese Frage steht also seit fast einem Jahr mit einer Antwort da, und ich füge endlich etwas hinzu, damit ich etwas einigermaßen Korrektes akzeptieren kann (nichts gegen Christoph), und dann tauchen zwei Leute aus dem Nichts auf, um Versionen derselben Sache anzubieten, die ich gepostet habe. Unglaublich. </snark>

3voto

Randal Schwartz Punkte 33384

Wie ich schon oft auf #git gesagt habe:

git-svn ist wie ein fliegendes Auto. Jeder will ein fliegendes Auto, bis er merkt, dass ein fliegendes Auto entweder als Auto oder als Flugzeug ziemlich schlecht ist.

Die wirkliche Lösung ist, so schnell wie möglich ganz von SVN wegzukommen. Verwenden Sie git-svn für eine einmalige Migration und stellen Sie dann alle um. Git ist pas so schwer zu lernen.

10 Stimmen

Ihre eigentliche Lösung setzt voraus, dass die Möglichkeit besteht, von Subversion wegzugehen. Wenn man nicht gerade einen neuen Job annimmt, ist das manchmal nicht der Fall.

1voto

Sophana Punkte 11

Mit git und git-svn 1.7.1 scheint der Test, den ich gerade durchgeführt habe, gut zu funktionieren.

git svn init [url]
git svn fetch

müssen Sie dann einen Dummy-Zweig erstellen und auschecken, um in den Master-Zweig pushen zu können.

git checkout -b dummy

Dann können Sie es klonen ( git clone ... ) in ein anderes reines Git-Repositorium, ändern Sie es, übertragen Sie es ( git commit ) dann drücken ( git push ) in das git-svn-Repositorium.

zurück zum git svn Repo:

git checkout master
git svn dcommit

wird alle Git-Commits, die gepusht wurden, übertragen.

0 Stimmen

Damit ist die Frage noch nicht beantwortet. Sie haben kein separates Git-Verzeichnis, wenn Sie tun, was Sie schreiben.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X