Ich lerne mercurial als meine Solo-Software. Mit anderer Verwaltungssoftware können Sie Änderungskommentare über Tags in den Dateikopf einfügen. Mit hg kommentieren Sie die Änderungsmenge, und das kommt nicht in die Quelle. Ich bin eher an zentrale Kontrolle wie VSS gewöhnt.
Warum sollte ich den Dateiverlauf in den Header der Quelldatei einfügen? Sollte ich mercurial den Verlauf mit meinen Changeset-Kommentaren verwalten lassen?
Lassen Sie das Quellcodeverwaltungssystem damit umgehen.
Wenn Sie Änderungsdetails in die Kopfzeile eingeben, wird es bald unhandlich und überwältigt den tatsächlichen Code.
Zusätzlich, wenn der SCM das Konzept der Änderungslisten hat (wo viele Dateien in einer einzigen Änderung gruppiert sind), dann können Sie den Kommentar so schreiben, dass er auf die gesamte Änderung und nicht nur auf die Änderungen in der einen Datei angewendet wird (wenn das Sinn macht), geben Sie ein klareres Bild von, warum die Änderung erforderlich war.
Ja; Lassen Sie das Quellcodeverwaltungssystem Ihre Changeset-Kommentare verarbeiten. Der Grund dafür ist, dass es wesentlich sinnvoller ist, wenn Sie das Änderungsprotokoll später betrachten und versuchen, herauszufinden, was zwischen zwei Versionen einer Datei vor sich geht - das Quellcodeverwaltungssystem kann den Änderungskommentar anzeigen, um die Situation aufzuklären .
Es gibt keinen Grund, einen Dateiverlauf manuell zu verwalten, wenn die SCM-Software zur Lösung dieses Problems viel besser geeignet ist. Allzu oft sehe ich unvollständige Dateiverläufe in der Quelle, was wirklich weh tut, weil die Leute fälschlicherweise annehmen, dass es korrekt ist.
Der Unterschied besteht nicht darin, ob es sich um ein zentralisiertes oder verteiltes VCS handelt, es geht vielmehr darum, was geändert wird.
Als ich zu .Net wechselte, schien die Anzahl der für jede einzelne Änderung aktualisierten Dateien in die Höhe zu schnellen. Wenn ich die Änderung in jeder Datei protokollieren müsste, würde ich nie wirklich etwas erledigen. Durch das Kommentieren der Änderungen ist es egal, wie viele Dateien ich aktualisieren musste.
Wenn ich jemals alle Änderungen für eine bestimmte Änderung identifizieren musste, kann ich zwischen den beiden Versionen des Projekts unterscheiden.
Der größte Unterschied (und der größte Vorteil), den ich beim Wechsel von SourceSafe sah, war der Wechsel von dateibasierten zu projektbasierten Commits. Sobald ich mich daran gewöhnt hatte, hörte ich auf, alle Kommentare mit Änderungen des Protokolltyps zu versehen.
(Als Nebeneffekt habe ich festgestellt, dass meine Kommentare zur Prozessbeschreibung besser geworden sind)
Ich bin kein großer Befürworter, den Code mit Änderungskommentaren zu verschwenden. Für den Fall, dass sie benötigt werden, können sie im SCM nachgeschlagen werden (zumindest für die SCM-Varianten, die ich verwendet habe). Wenn Sie sie in der Datei speichern möchten, sollten Sie sie am Ende anstatt am Anfang einfügen. Auf diese Weise müssen Sie nicht über die (uninteressanten, zumindest für mich) Kommentare nach unten scrollen, bevor Sie zum eigentlichen Code gelangen.
Noch eine Abstimmung, damit das SCM-System die Eincheckkommentare verarbeiten kann, aber ich muss noch etwas hinzufügen.
Bei einigen Systemen können Sie RCS-Tags in Ihrem Quellcode verwenden, bei denen der SCM den Änderungsverlauf direkt in die Quelldatei einfügen kann, die automatisch festgeschrieben wird. Klingt wie ein schönes Gleichgewicht, denn die Geschichte ist dann im SCM-System und dann automatisch in den Quellcode selbst.
Das Problem ist, dass dieser Prozess die Quelldatei ändert . Ich denke, das ist eine schlechte Idee, weil die Datei nicht auf der Festplatte geändert werden kann, nachdem Sie den Kommentar eingefügt haben. Wenn Sie ein guter Ingenieur waren, sollten Sie Änderungen vor dem Commit erstellt und getestet haben. Wenn sich Ihre Quelle nach dem Commit ändert, dann haben Sie im Grunde einen Build, der defekt sein könnte - aber die meisten Engineers werden nach einem Commit nicht bauen - warum sollten sie?
Aber es ist nur ein Kommentar, den Sie sagen! Richtig, aber ich hatte einen Fall, wo es Code in meiner Quelldatei gab, der seltsam genug hatte, wie ein RCS-Header-Tag zu sehen und dieser Teil des Codes wurde beim Einchecken ersetzt, wodurch mein Code verschandelt wurde . Einfach genug, um zu beheben, aber schlecht, dass ein Build für mehr als 20 Benutzer gebrochen wurde
Viel leichter zu vergessen, die History in der Quelle zu pflegen, da man (imo) commits immer in das Quellkontrollsystem kommen soll, dass das Problem disappt. Auch wenn viele Dateien vor dem Festschreiben geändert werden, ist das Ändern des Verlaufs in jeder Datei lästige Arbeit. Dies ist wirklich einer der Punkte mit scm.
Ich habe Erfahrung damit. Ich hatte die Datei Geschichte in den Kommentaren, es war schrecklich . Nichts als Müll, manchmal müssten Sie fast 1 k Zeilen Codeänderungen herunterscrollen, bevor Sie endlich zu dem kamen, was Sie wollten. Ganz zu schweigen von Sie verlangsamen andere Aspekte Ihres Build-Prozesses, indem Sie Ihrem Quellcode-Baum mehr kb hinzufügen.
Tags und Links mercurial version-control