Ist es in Ordnung, Mercurials Umbenennungsfunktion zu "missbrauchen", um die Bewegung von Codeblöcken zu verfolgen?

Question

Manchmal finde ich, dass ich eine Datei habe, die im Laufe der Zeit gewachsen ist, um mehr Klassen/Funktionen/whatevers zu enthalten, als ich mag. Es ist Zeit zu refaktorisieren! Normalerweise finde ich in diesem Fall, dass meine eine Datei zu mehreren wird: sich selbst und mehrere andere Dateien, von denen jede einzelne Segmente der Datei enthält.

Leider "nur" diese neuen Dateien erstellen "bricht" Geschichte ein wenig - es ist schwer zu sagen, dass diese Funktionen ursprünglich aus einer anderen Datei stammten. Es ist noch schlimmer, wenn während des Refactorings noch andere Änderungen am Code vorgenommen wurden.

Einer meiner Kollegen fanden heraus, dass er die Umbenennungs Funktionalität wie dies etwas zu tun „missbrauchen“ könnte:

hg rename --after original_file new_file_1 
hg rename --after original_file new_file_2 
hg rename --after original_file new_file_3 
hg add original_file 

Das Ergebnis ist, dass jedes der neuen Dateien wie ein Umbenennungs sieht mit dem Rest der Datei entfernt, und die ursprüngliche Datei sieht so aus, als hätte sie die entfernten Blöcke verloren. Bisher scheint das ideal zu sein. Allerdings mache ich mir Sorgen, dass diese mehrfache Umbenennung einige verwirrende Zusammenführungen nach unten verursacht.

Gibt es etwas falsch mit dieser "mehrere umbenennen" Ansatz?

Answer 1

Sie sollten sicherstellen, dass Sie know what hg copy really means, bevor Sie dies tun.

Kurz gesagt, von original_file zu new_file_1 Kopieren eine Datei fügt einen Link, dass Mercurial in Zukunft nutzen wird verschmilzt , wenn und nur wenn es nicht new_file_1 im gemeinsamen Vorfahren finden. Dies ist normalerweise nur bei der ersten Zusammenführung der Fall, nachdem Sie die Kopie erstellt haben.

könnte Ein Diagramm veranschaulicht dies besser:

old --- edit old --- edit in old copied to new --- edit old --- merge 
    \    /       /
    copy old new --/------- edit new ------------/ 

Wir sind mit einer changeset beginnen, wo Sie die Datei old haben. Sie bearbeiten dann old auf einem Zweig und kopieren old in einem anderen Zweig auf new. In der ersten Zusammenführung wird die Bearbeitung zu old in new kopiert. In der zweiten Zusammenführung gibt es keine spezielle Behandlung für new, da new im gemeinsamen Vorfahren (der copy old new Changeset) gefunden wird.

Das bedeutet für Ihren Fall, dass es einen großen Unterschied in zukünftigen Zusammenführungen gibt, abhängig davon, wann die Leute die copy old new sehen. Wenn Sie jeden dazu bringen können, den Ausgangspunkt zu verwenden, dann ist alles in Ordnung. Aber wenn jemand Zweige von der old Änderungsmenge abzweigt und in diesem Zweig tatsächlich old bearbeitet, dann werden sie Zusammenführungskonflikte erhalten, wenn sie versuchen, mit der Änderungsmenge copy old new zu verschmelzen.

Genauer gesagt, erhalten sie Zusammenführungskonflikte, wenn sie einen Teil der Datei old bearbeitet haben, die nicht in die Datei new kopiert wurde.Die Zusammenführungskonflikte weisen Sie darauf hin, dass eine Änderung in old vorgenommen wurde, die in new kopiert werden muss. Wenn Sie jedoch haben wirklich

hg copy old new1 
hg copy old new2 
hg copy old new3 

dann werden Sie irrelevant merge Konflikte in zwei der drei neuen Dateien.

Wenn Sie die old Datei nur gelöscht hatte, und drei neue Dateien, dann würden Sie noch einen Merge-Konflikt hier: Sie

gefragt werde

remove changed old which local deleted 
use (c)hanged version or leave (d)eleted? 

Ob Sie eine Eingabeaufforderung angezeigt, um zu sehen bevorzugen oder sehen die Merge-Tool Start-up ist an Ihnen - aber jetzt wissen Sie die Folgen von hg copy (oder hg rename --after, es ist wirklich das Gleiche).

Answer 2

Einfacher ist hg copy dafür zu verwenden:

hg copy original_file new_file_1 
hg copy original_file new_file_2 
hg copy original_file new_file_3 

Nun sind alle 3 die ursprüngliche Geschichte. Aber, so oder so, das ist vollkommen in Ordnung und gewöhnlich gemacht.