Kann verschiedene git-svn-Klone der gleichen SVN-Repository erwarten zu können, Änderungen teilen dann git svn dcommit?

Question

Ich habe sehr viel „geht aus dem SVN auf Git“ lesen und andere „git-svn workflow“ Artikel über das Internet, und immer noch denke ich, sie oft mit allzu einfachen Situationen umgehen. Sie werden oft an Jungs gedacht, die nur git verwenden möchten und lokal hacken, ohne die volle Leistung des git zu verwenden, wie Pull, holen, fusionieren und dergleichen zwischen mehreren Entwicklern, die würden alle SVN-Repository mit git-svn geklont, dann erwartet nach wie vor in der Lage sein, ihre Änderungen jederzeit auf die (offizielle) sVN-Repository zu schieben und wieder zu arbeiten in git und teilen ihre Sachen etc.

Wenn diese Artikel zugeben Sie nicht alles tun, können Sie in der reinen git tun würde, sind die Folgen und mögliche Schraube ups nie deutlich erklärt (oder vielleicht ist es nur mich?). Selbst der git-svn Manpage erwähnt Einsprüche, aber nicht wirklich in einer umfassenden Weise.

Nach dem, was ich gelesen habe, fühle ich es Probleme geben könnte, wenn git-svn in dieser spezifischen Art und Weise verwendet wird, die ich weiter unten beschreiben werde. Kann mir jemand sagen, ob ich recht darüber bin?

Hier ist die „wollte“ Art und Weise, Dinge zu tun:

1. Wir haben ein Projekt in einer SVN-Repository
2. Entwickler A git-svn-Klon ist die SVN-Repo. Er beginnt die Dinge vor Ort zu hacken
3. Entwickler B git-svn-Klon ist die gleiche SVN-Repo. Er beginnt Dinge auf eigene Faust zu hacken.
4. Danach für einige Zeit zu tun, möglicherweise Devs C Hinzufügen / D / ... und mit anderen Entwicklern, die „Standard“ svn verpflichtet zum ursprünglichen Repo tun, würden Sie wollen die git Benutzer ihren Code zu teilen und alle Arten zu tun von git Magie.
5. Jedes dieser git Benutzer möchte in der Lage sein, die jetzt drücken fusionierte Änderungen SVN (dcommit?)

Meine Frage ist: träume ich? Las ich vor einiger Zeit in einem Git-Buch, das ich denke, dass git-svn-clone git Repositories erstellen könnte, die natürlich ein „Spiegel“ des SVN Repo sind, sondern dass git repos erstellt auf diese Weise von verschiedenen Entwicklern anders hätte " ids“und Commits würden unterschiedliche Hashes haben. So war mein Verständnis, dass dieser git repos würde keine gemeinsamen git Vorfahren teilen, und somit nicht in der Lage sein, all git Befehle, die Sie teilen müssen verwenden, fusionieren, und so weiter. Ist es wahr, werden wir Probleme mit diesem Workflow stellen?

Manchmal las ich dies getan werden könnte, indem zumindest einen „offiziellen“ bare Git Repository, das wäre die einzige git-svn-geklont zu werden, und alle git Benutzer müßten Form diesen starten. Dann brauchen Sie jemanden, der verantwortlich für diese zentralen git Repo ist, und sammelt die Änderungen zwischen dem git Devs, vor allem auf den SVN Repo dcommiting. Dies wäre die einzige Möglichkeit für git Benutzer zu sein „nicht bewusst“, dass der ursprüngliche git Repo aus dem SVN kommt, und läßt sie alle git Befehle verwenden, wie sie wollen. Die einzige Person, müssten sowohl fließend sein in git und svn (und wissen über git-svn Einsprüche) wäre der „Manager merge“ (oder was auch immer er genannt wird).

Bin ich völlig Missverständnis git-svn Einsprüche? Gibt es einen einfacheren Weg, dies zu tun?

Answer 1

Das Problem ist Schritt 4 natürlich. Ein dcommit versucht, Ihre lokale Geschichte an den Server zu wiederholen. Dcommit gibt vor, dass Sie einen SVN-Client sind. Wenn nun der Code, den Sie dcommitting ist nicht nur von Ihnen, das ist etwas, das schwer zu SVN dcommit.

Hier ist, was die Guru schreibt zu diesem Thema:

  

  
• Aus Gründen der Einfachheit und Interoperabilität mit SVN, es ist   empfohlen, dass alle git-svn Benutzer   Klon, Abruf- und dcommit direkt aus   der SVN-Server (der Remote-SVN   Repository, das ist), und vermeiden Sie alle   GIT-Klons / pull / merge / Push-Operationen   zwischen git Repositories und Zweigen   die entweder über git Svn abgerufen   Klon und die auch verwendet werden, um Push   zurück Changesets in die Fernbedienung SVN   Repository.
  
• Die empfohlene Methode von Code zwischen git Filialen Austausch   und Benutzer ist git format-patch und git   ist, oder einfach nur git svn dcommit zum SVN   Repository.
  
• Da git svn dcommit verwendet git svn rebase intern, keine git Zweige wir   git push to vor git svn dcommit auf   sie erfordert zwingt ein Überschreiben   der bestehenden ref auf der Fernbedienung   Repository. Dies ist im Allgemeinen   als schlechte Praxis finden Sie in der   git-Push-Dokumentation.
  
• Running git merge oder git pull wird nicht auf einem Zweig empfohlen wir planen   git svn dcommit aus. SVN nicht   verschmilzt in jedem angemessenen darstellen oder   nützliche Art und Weise, so dass Benutzer mit SVN   kann keine Merges sehen wir gemacht haben.   Außerdem, wenn wir git fusionieren oder git   Ziehen von einem git Zweig, auf dem eine   Spiegel eines SVN Zweig, GIT Svn   dcommit kann auf die falsche begehen   Zweig.
  
• git clone nicht klonen Zweige unter dem refs / remotes / Hierarchie oder   jeder GIT-Svn Metadaten oder Konfig. Damit   Repositorys erstellt und verwaltet mit   mit git-svn sollte verwenden rsync   für das Klonen, ist, wenn das Klonen getan werden   überhaupt.
  
• Wir sollten die --amend Möglichkeit git commit auf einer Änderung verwenden wir   bereits dcommitted. Es ist   als schlecht Praxis --amend   Commits haben wir bereits zu einem geschobenen   Remote-Repository für andere Benutzer und   dcommit mit SVN ist derjenigen analog.   Weitere Informationen hierzu finden sich   bei Ändern begehen eine einzelne und    Probleme mit Geschichte neu zu schreiben.
  

Answer 2

Ich habe in letzter Zeit eine Menge mit diesem experimentieren und ich denke, mit einem Setup kommen verwaltet, die etwas funktioniert. Ja, es ist ein strenges rebase-only-Regime, ja, es ist kompliziert, aber Sie bekommen Git zu verwenden, um lokal arbeitet (Geschwindigkeit, Geschichte, versteck, Index, usw.).

Sie können mit Zweigen hinter den Kulissen, wenn Sie mit anderem Git-Benutzer in Ihrem Team zusammenarbeiten, denke ich, aber nicht persönlich zu viel mit diesen experimentiert. Solange Sie das Protokoll vor dcommitting linearisieren sollte es funktionieren.

Hier ist die kurze Version (wiederholt eine Menge, was bereits gesagt worden ist):

1. Klonen Sie die Subversion-Repo zu einer "Abrufen" Repo auf einem zentralen Server
2. Init einer "nackten" Repo auf dem gleichen Server
3. Push vom fecthing Repo auf den blanken Repo
4. Haben Entwickler klonen die nackten Repo und dann
   5. git svn init svnurl den git-svn remote zu konfigurieren und
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master so git-svn hat einen Zeiger auf eine Revision
5. Automatisch (commit) das "Abrufen" repo Svn Fütterungsmaterial, und drückt auf den blanken repo
6. Entwickler ziehen aus dem nackten Repo mit git pull --rebase
7. Entwickler laufen git svn dcommit müssen zuerst oben bei den neueren Versionen der update-ref wiederholen von SVN kommen.

Es gibt eine Abbildung des Workflows auf dieser Seite (ich brauche mehr Rufpunkte, bevor ich das Bild inline kann). Update: Hier gehen wir:

Answer 3

Was ich zu tun pflegte, ist eine anfängliche git svn Klon erstellen, dann teilte er unter den developpers .git git verwenden, so hatten wir genau die gleichen Referenzen.
Es schien, richtig zu arbeiten, wie wir in der Lage waren „spezifische git Funktionen“ zwischen git Benutzern zu verwenden, solange wir in einem linearen Baum blieben (dh Rebasing statt Zusammenführung).

Answer 4

Sobald Sie in „verteilt“ -Ausgabe Schritt, Sie sind mit einem nackten git Repo besser bei Entwicklern geklont.
In Bezug auf die Export-Import-Phase für die Öffentlichkeit SVN Repo, für andere zu verwenden, um die Skripte
git2svn und svn2git helfen können, kapseln die Magie.

Andere Überlegungen, wenn in Git und SVN repos arbeitet in der Frage gefunden " Workflow und helfen mit git, 2 sVN-Projekten und einem einzigen „workcopy“ "

Answer 5

Es ist ein Werkzeug, das das Problem des Teilens Git-Repository mit Subversion-Repository synchronisiert löst.

SubGit ist ein Git-SVN bidirektionaler serverseitigen Spiegel.

Ein SubGit in Subversion-Repository installieren kann und erhalten Git-Repository automatisch synchronisiert mit SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit installiert pre-commit und post-commit Haken in Subversion-Repository, Pre-Empfangs- und Post erhalten Haken in Git-Repository. Als Ergebnis übersetzt sie sofort eingehende Änderungen von SVN und Git Seiten. Nach SubGit Installation Entwickler all Git-Client verwenden, können mit Git-Repository zu klonen und arbeiten.

SubGit beruht nicht auf git-svn, verwendet er seine eigene Übersetzungs-Engine unser Team entwickelt hat. Weitere Einzelheiten hierzu können Sie unter SubGit vs. git-svn Vergleich. Allgemeine Dokumentation über SubGit ist verfügbar hier rel="nofollow">.

Die Version 1.0 von SubGit lokalen Zugriff auf Subversion-Repository benötigt, das heißt SVN und Git-Repositories auf demselben Host befinden. Aber mit der Version 2.0 werden wir Git-Proxy-Modus einführen, wenn Subversion und Git-Repositories überall lokalisiert werden kann und nur Git-Repositories haben SubGit in ihnen installiert, das heißt Subversion-Repositorys bleiben unberührt.

SubGit ist ein kommerzielles Produkt. Es ist für Open-Source-akademisches Projekt und auch für Projekte mit bis zu 10 Committer.

Disclaimer: Ich bin einer von SubGit Entwicklern

.

Answer 6

fand ich diese Blog-Post , die vorschlägt, einen eigenen Zweig für die Synchronisierung mit der Subversion-Repository zu halten, so dass es immer noch möglich sein wird, in dem Master-Zweig Push / Pull zu tun.

Answer 7

Eines der Probleme, die ich mit git-svn wahrnehmen ist, dass es speichert den git-svn-id in dem Commit-Kommentar; weil diese umschreibt, dass begehen, ändert es ist SHA1, so dass Sie es nicht überall schieben Menschen es teilen wird.

ich eigentlich lieber bzr-svn denn anstatt den BZR revid in der Remote-SVN-Revision mit den SVN Revisionseigenschaften speichert stattdessen Funktion, die keine lokale Revision Rewrite bedeutet. Es hat auch die Eigenschaft erwünscht ist, dass zwei unabhängige Zerren des gleichen SVN Zweig in identischen und interoperable BZR Zweigen führen.