Was Passiert, Commit-Protokolle, die auf eine Niederlassung Nach der Fusion?

Szenario:

  1. Programmierer erstellt ein Zweig für Projekt 'foo', genannt 'my_foo' auf revision 5
  2. Programmierer macht mehrere änderungen an mehreren Dateien arbeitet er an der 'my_foo' - Funktion.
  3. Am Ende jeder wichtigen Schritt, sagen Sie das hinzufügen von mehreren neuen Funktionen zu einer Klasse, der Programmierer ist ein svn commit auf die entsprechenden Dateien, deshalb Begehen Sie in den Zweig
  4. Nach mehreren Wochen und vielen commits später (jeder commit mit einem commit-log zu beschreiben, was er auch Tat), der Programmierer führt den Zweig auf den Stamm zurück:

#Assume the following is being done from inside a working copy of the trunk:
svn merge -r 5:15 file:///path/to/repo/branches/my_foo

Hazzah! er ist verschmolzen alle seine änderungen zurück in den trunk! Es gibt viel Jubel und trinken Mountain Dew.

Nun lassen Sie uns sagen, ein anderer Programmierer kommt eine Woche später und aktualisiert Ihre Arbeitskopie von revision 5 bis revision 15. "Wow", sagen Sie. "Ich Frage mich, was hat sich geändert seit der Version 5". Der Programmierer braucht dann eine svn status auf Ihre Arbeitskopie und Sie bekommen so etwas wie dieses:

------------------------------------------------------------------------ 
r15 | programmer1 | 2010-03-20 21:27:04 -0400 (Sat, 20 Mar 2010) | 1 line 

Zusammenführen Version 2.0 Änderungen in den trunk 
------------------------------------------------------------------------ 
r5 | programmer2 | 2010-02-15 10:59:55 -0500 (Mon, 15 Feb 2010) | 1 line 

Hinzugefügt assets/images/tumblr_icon.png-Stamm

Was zum Teufel ist passiert, um all die Notizen, die andere Programmierer setzen mit alle seine commits in seiner Branche? Das tun diejenigen, die nicht mitgezogen werden, über die während einem Zusammenführen? Bin ich verrückt oder nur etwas vergessen?

InformationsquelleAutor Levi Hackwith | 2010-03-26
  1. 9

    Antwort veraltet ist, jetzt haben wir svn log -g.

    Nein, Sie sind nicht verrückt. Das ist, wie es funktioniert, leider.

    Die besten Sie tun können, gehören in die commit-Nachricht für die Zweig-url und die revision-Nummer, so dass man manuell suchen den log für diesen Zweig.
    (Die Daten sind noch da, natürlich).

    Aber Sie wissen nicht, welche der änderungen, die sich vorgenommen haben, es in den Kofferraum und welche nicht.

    Wenn es keine oder nur wenige änderungen auf dem Stamm, es könnte eine option sein, zu tun, ein reverse-merge (merge vom trunk in den branch) und ersetzen Sie dann den Stamm mit Zweig.
    Diese Art der Argumentation kann man auch auf einzelne Unterordner (z.B.: ersetzen der XML-parser-Implementierung Unterordner aus der Branche, halten Sie den rest).
    Ersetzen von Ordner (mit svn delete, svn copy) hält die revision der Geschichte.

    Für Dateien, die wurden neu Hinzugefügt, während der Zusammenführung, Ihre revision history kopiert werden können über vom ast, wenn Sie den Befehl svn copy. Nicht sicher, ob der merge-Befehl beinhaltet die Unterstützung für diese, obwohl.

    Könnte es interessant sein, zu wissen, ob es ein tool für den svn, der einen "Stellungswechsel" (wie bei git oder mercurial). Schaffen würde, die einzelnen commits für jede änderung auf dem Zweig. Auf der anderen Seite, vielleicht einzelne commits zu viel Unordnung.

    Beste Empfehlung, die ich geben kann ist, um einen guten UI, wie Trac, das macht es leicht zu untersuchen die revision der Geschichte, so dass Sie sehen können, was passiert auf dem ast.

    • Ausgezeichnete Informationen, danke. Follow-up-Frage: wenn ein Zweig zusammengeführt wurde, um Stamm, sollte es nicht gelöscht werden, da es nicht mehr gebraucht wird? Oder sollte es gehalten werden, für immer? Wenn ich eine Verzweigung, nicht alle die commit - / revisions-Daten, die mit ihm zu gehen?
    • Ich würde sagen, löschen Sie den Zweig so schnell wie möglich (D. H. wenn alles zusammengeführt wurde oder obsolet geworden) zu vermeiden, Unordnung/Verwirrung. Sie können wiederherstellen der Zweig später, wenn es sein muss (durch die Schaffung einer neuen Niederlassung als eine Kopie von eine alte revision). Nichts in Subversion ist immer gelöscht.
    • Also, wenn jemand sehen wollte begeht, die von einer gelöschten Zweig, würden Sie haben zu prüfen, die branchand dann ein svn-log? Oder können Sie etwas mit svn log direkt?
    • Sie können tun, "svn log", wenn Sie wissen, eine Versionsnummer, wenn die Filiale noch existiert (die Sie sollten in der Lage sein zu finden, mit dem Rüssel log, suchen für den merge-commit)
    • Diese Lösung ist nicht "das beste was Sie tun können", sollte es erwähnt haben svn log -g
    InformationsquelleAutor Thilo
  2. 43

    Versuchen svn log -g zu gehören merge-Historie gespeichert ist seit Subversion 1.5.

    • +1 das ist die Antwort, die wir Googler müssen.
    • +1 Absolut. Es sollte jedoch beachtet werden, dass wenn der merge die Datei Ersetzt, dann Revisionen in der Mitte erscheinen nicht im log. (Um zu bestimmen, Ersetzt Dateien, werden Sie sehen, wie "R" in der svn log --verbose des merge-revision). Fuhr mich verrückt zu versuchen, zu verstehen, warum die Revisionen in der Mitte fehlten.
    InformationsquelleAutor Ted Percival
  3. 15

    TortoiseSVN hat "zusammengeführte Revisionen Einschließen" aktivieren Sie das Kontrollkästchen unten auf "Protokoll Anzeigen" Dialogfeld zu schließen die Kommentare begangen, um die Zweige.

    • Gibt es etwas, was vor allem zu tun zu haben, begeht in den trunk mit svn merge?
    InformationsquelleAutor albtvenki
  4. 2

    Gute Antworten... Wenn Sie das auch wollen zu wissen die eingecheckten Dateien und potenziell der Filiale name, bundle-v [--verbose] option -g [--use-merge-history].

    Beispiel:

    svn log -vg

    Die Ausgabe wird der vollständige Pfad der eingecheckten Dateien (auch die zusammengeführte Zweig), sowie ein (aus 'revision_url') - Nachricht für die hinzugefügten Dateien in der revision mit der Zusammenführung.

    InformationsquelleAutor userNineThousand
Schreibe einen Kommentar