Beim Testen der Funktionalität in Subversion habe ich versucht, den Anwendungsfall zu testen, der im Unterabschnitt Änderungen rückgängig machen im Abschnitt "Einfaches Zusammenführen" des Kapitels "Verzweigen und Zusammenführen" von svnbook . Ich benutze Version 1.6.4, aber der Text für diesen Abschnitt ist in beiden Versionen des Buches identisch.
In meinem Arbeitskopie-Verzeichnis bearbeite ich eine Datei testcode.py, füge eine Zeile pro Bearbeitung hinzu und begehe nach jeder Bearbeitung. Nach mehreren Commits lautet die Datei wie folgt:
%Vor%Die Revisionsnummern im Repository stimmen mit den Zeilen in der Datei überein, so dass in /trunk/testcode.py@rN die letzte Zeile der Datei diejenige ist, die mit rN endet. Was ich tun möchte, ist die Zeile in r4 zu entfernen, alles andere vor und nach unverändert zu halten.
Nach dem Beispiel im Abschnitt Rückgängigmachen von Änderungen des svnbooks führe ich den Befehl
aus %Vor%Dies erzeugt einen Konflikt (beim Ausführen dieses Befehls, nicht beim Festschreiben), wobei die Datei zum Zusammenführen links bis zur Zeile r4 alles enthält und die Datei zum Zusammenführen rechts alles bis zur Zeile r3 enthält. Mit anderen Worten, der Befehl scheint nicht die vorherige Änderung zu entfernen, sondern die gesamte Datei auf die Revision 3 oder 4 zurückzusetzen und die Änderungen in nachfolgenden Revisionen zu entfernen (in diesem Fall 5 und 6).
Wie ich das Beispiel im svnbook gelesen habe, bei dem der Benutzer eine in Revision 30 festgeschriebene Änderung rückgängig macht und das Ergebnis ohne Konflikte an Revision 350 übergibt, sollte der Befehl, den ich ausgeführt habe, eine Datei mit einem SVN-Status von M ergeben haben das behält alle Zeilen mit Ausnahme der in r4 endenden.
Liest ich das Beispiel des Buches falsch, ist das Beispiel falsch oder gibt es eine andere Form von Benutzerfehler, in die ich unwissend geraten bin?
Das grundlegende Problem ist, dass der Diff-Algorithmus von Subversion Änderungen am Anfang und am Ende von Dateien auf eine Weise behandelt, die nicht unbedingt intuitiv ist. Ihr Beispiel trifft diese Ecke, während die meisten Änderungen in der Wildnis dies nicht tun. Betrachten Sie eine Datei, die nach einer Reihe von Commits folgendermaßen aussieht:
%Vor%Wenn Sie versuchen, die Commits an den Anfang oder das Ende der Datei zurückzusetzen (in den Revisionen 2 und 4 im Beispiel), besteht ein Konflikt. Das Zurückstellen der Änderung in die Mitte der Datei funktioniert wie erwartet.
Vom Konzept her könnte es hilfreich sein, Changesets als einen Bereich zu betrachten, der durch umgebende Linien begrenzt ist. Eine Änderung in der Mitte einer Datei wird durch die umgebenden unveränderten Zeilen begrenzt. Der Umfang einer Änderung am Anfang oder Ende einer Datei erstreckt sich bis zum Anfang oder Ende der Datei , unabhängig davon, wie weit der Punkt später verschoben wird .
Im obigen Beispiel befindet sich die in Revision 5 hinzugefügte zweite Zeile genau in der Mitte des Bereichs von Revision 4. Auf die gleiche Weise, wie Sie erwarten würden, dass ein Konflikt Version 10 umkehrt, weil Änderungen in Revision 11 mitten drin sind:
%Vor%Sie sollten hier einen Konflikt erwarten, aus dem gleichen Grund:
%Vor%Beachten Sie, dass dies nur als konzeptuelle Erklärung dafür gedacht ist, warum der Anfang und das Ende der Datei scheinbar anders behandelt werden und nicht als eine umfassende Erklärung für das Verständnis von Subversions Merge-Prozess.