Warum kann ich eine SVN-Commit-Nachricht nicht bearbeiten?

Ich benutze SVN. Manchmal vermisse ich etwas, wenn ich eine Commit-Nachricht schreibe. Aber sobald es festgeschrieben wurde, kann es nicht wiederhergestellt werden, und selbst ich kann die Nachricht nicht bearbeiten. Warum haben sie die Bearbeitungsfunktion nicht eingefügt?

version-control svn

— Sanghyun Lee
quelle

Erinnert mich an die Geschichte von Dave.cpp auf theedailtywtf

— Falcon

Verwenden Sie einfach git , es ermöglicht das Zusammenführen von Commits, das Bearbeiten von Nachrichten und das Bearbeiten Ihres Verlaufs nach Belieben.

— SK-logic

Oder wenn Sie nicht können, dann verwenden Sie git-svnund niemand wird klüger sein.

— Matthew Scharley

@Matthew: wie um alles in der Welt mit git-svn können Sie den Verlauf in einem SVN-Repo mit deaktivierter Bearbeitung des Verlaufs ändern?

— gbjbaanb

@gbjbaanb: Wäre es nicht, wenn Sie bereits einen Push-up auf den SVN-Server durchgeführt hätten. Wenn Sie jedoch nur ein lokales Commit durchgeführt haben, können Sie die Commit-Nachricht dennoch ändern, bevor Sie sie in das Live-Repo übertragen.

— Matthew Scharley

Antworten:

Gemäß den SVN-FAQ können Sie festlegen, ob der Repository-Administrator dies aktiviert hat oder ob Sie über lokalen Administratorzugriff auf das Repository verfügen .

Dies ist jedoch wahrscheinlich eine schlechte Idee. Sie verändern praktisch die Geschichte. Einer der Punkte der Versionskontrolle ist die Verwaltung eines Verlaufs und eines Prüfpfads für das Projekt. Das Zulassen von willkürlichen Änderungen an der Historie besiegt den Audit-Trail. Stattdessen würde ich empfehlen, dass Sie kleinere Commits ausführen, kurze, aber explizite Commit-Nachrichten schreiben und Ihren persönlichen Workflow verbessern, um diese Fehler zu vermeiden.

— Thomas Owens
quelle

@Matthew Selbst in git ist die Veränderung der Geschichte zu jedem Zeitpunkt meiner Meinung nach eine schreckliche Idee. Die Historie soll als Audit-Trail dienen und sollte zu keinem Zeitpunkt und aus irgendeinem Grund von irgendjemandem geändert werden.

— Thomas Owens

Erstellen Sie daher einen Audit-Trail für die Festschreibungsnachricht, da in der Regel das Ändern der Festschreibungsnachricht dazu dient, die Verfolgung des Projektverlaufs zu vereinfachen .

— Peter Taylor

Angenommen, ich stelle fest, dass eine Commit-Nachricht, die ich vor einem Monat eingegeben habe, irreführend, verwirrend und ausgesprochen falsch ist . Sollte ich nicht in der Lage sein, eine Korrekturnotation hinzuzufügen, die von allen gesehen wird, die die falsche Nachricht sehen? (Ich bin damit einverstanden, dass die ursprüngliche Nachricht ohne Änderungen leicht verfügbar sein und die Änderung selbst nachverfolgt und mit einem Zeitstempel versehen werden sollte. Ich bin jedoch nicht der Meinung, dass dies eine "Änderungshistorie" darstellt.)

— David Schwartz

Falsche Informationen sind inakzeptabel, daher dürfen Personen diese Informationen nicht berichtigen oder klarstellen, da dies ihre Fehlverhalten verbergen würde. Beeindruckend. Einfach wow.

— David Schwartz

Sie fangen ehrlich an, wie eine Selbstparodie auszusehen. "Es muss richtig sein, deshalb darf es niemals korrigiert werden."

— David Schwartz

Grundsätzlich müssen Sie über Administratorrechte (direkt oder indirekt) für das Repository verfügen, um dies zu tun. Sie können das Repository entweder so konfigurieren, dass alle Benutzer dies tun können, oder Sie können die Protokollnachricht direkt auf dem Server ändern.

Überprüfen Sie die SVN- FAQ hier.
Protokollnachrichten werden im Repository als an jede Revision angehängte Eigenschaften gespeichert. Standardmäßig kann die Eigenschaft für Protokollnachrichten (svn: log) nach dem Festschreiben nicht mehr bearbeitet werden. Das liegt daran, dass Änderungen an Revisionseigenschaften (von denen svn: log eine ist) dazu führen, dass der vorherige Wert der Eigenschaft dauerhaft verworfen wird, und Subversion versucht, Sie daran zu hindern, dies versehentlich zu tun. Es gibt jedoch mehrere Möglichkeiten, wie Subversion eine Revisionseigenschaft ändern kann.

Die erste Möglichkeit besteht darin, dass der Repository-Administrator Änderungen an den Revisionseigenschaften aktiviert. Dazu erstellen Sie einen Hook mit dem Namen "pre-revprop-change" (in diesem Abschnitt im Subversion-Handbuch finden Sie weitere Informationen dazu). Der Hook "pre-revprop-change" hat Zugriff auf die alte Protokollnachricht, bevor sie geändert wird, damit sie auf irgendeine Weise erhalten bleibt (z. B. durch Senden einer E-Mail). Sobald Änderungen an den Revisionseigenschaften aktiviert sind, können Sie die Protokollnachricht einer Revision ändern, indem Sie die Option --revprop an svn propedit oder svn propset übergeben.
$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 
Dabei ist N die Versionsnummer, deren Protokollnachricht Sie ändern möchten, und URL der Speicherort des Repositorys. Wenn Sie diesen Befehl in einer Arbeitskopie ausführen, können Sie die URL weglassen.

Die zweite Möglichkeit zum Ändern einer Protokollnachricht ist die Verwendung von svnadmin setlog. Dies muss unter Bezugnahme auf den Speicherort des Repositorys im Dateisystem erfolgen. Mit diesem Befehl können Sie kein Remote-Repository ändern.
$ svnadmin setlog REPOS_PATH -r N FILE
Dabei ist REPOS_PATH der Speicherort des Repositorys, N die Revisionsnummer, deren Protokollnachricht Sie ändern möchten, und FILE eine Datei, die die neue Protokollnachricht enthält. Wenn der Hook "pre-revprop-change" nicht vorhanden ist (oder Sie das Hook-Skript aus irgendeinem Grund umgehen möchten), können Sie auch die Option --bypass-hooks verwenden. Seien Sie jedoch sehr vorsichtig, wenn Sie sich für diese Option entscheiden. Möglicherweise umgehen Sie solche Dinge wie E-Mail-Benachrichtigungen über die Änderung oder Sicherungssysteme, die die Revisionseigenschaften verfolgen.

Antwort von Kamil Kisiel auf eine ähnliche Frage zu Stack Overflow .

— Abimaran Kugathasan
quelle

Wenn Sie eine Antwort von stackoverflow kopieren und einfügen, sollten Sie sie mindestens als Anführungszeichen markieren und dem OP (in diesem Fall Kamil Kisiel) die Ehre erweisen. Link zum Original: stackoverflow.com/questions/304383/… Bitte bearbeiten Sie Ihre Antwort oder ich werde Sie abstimmen.

— Falcon

Da es sich um ein zentrales Versionskontrollsystem handelt - Sobald Sie eine Änderung festschreiben (und Ihre Festschreibungsnachricht gemäß der Konvention an die Festschreibung gebunden ist), kann jeder Benutzer mit Lesezugriff auf das Repository diese Informationen anzeigen. Es ist eine schlechte Idee, Informationen nach ihrer Verbreitung zu ändern , da die Menschen am Ende eine andere Meinung von "Realität" haben.

Verteilte Versionskontrollsysteme wie Git lindern dieses Problem, indem sie sicherstellen, dass die Bereitstellung von Informationen für andere atomar ist und keine zusätzlichen Informationen wie Commit-Nachrichten enthält. Hier gilt jedoch das gleiche Prinzip: Sie werden davon abgehalten, Dinge vor Ort zu ändern, die Sie bereits anderen zur Verfügung gestellt haben.

— l0b0
quelle

Sie könnten mehrere Versionen der Commit-Nachricht zulassen ...

— Alex Feinman

@ l0b0 Ist es objektiv nicht schlimmer, weiterhin falsche, irreführende oder schadensanfällige Informationen zu verbreiten? Für die Aufbewahrung von Aufzeichnungen müssen keine schlechten Daten gespeichert werden.

— user179700

@ user179700: Du hast recht. Es gibt eine grundlegend fehlerhafte Entwurfsannahme in allen VCS, die ich je gesehen habe: Ein Commit hat eine Commit-Nachricht, die unveränderlich ist. Wie Alex sagt, sollten wir "mehrere Versionen der Commit-Nachricht zulassen".

— l0b0

@ l0b0 Ich finde diese Frage umso interessanter, je mehr ich darüber nachdenke. Meine erste Reaktion war nach dem Vorbild von, schreibe nur sorgfältiger. Die derzeitige Praxis scheint den Prozess zu behindern. Ich frage mich auch, ob andere Systeme eine robustere Praxis implementieren. Zeit für eine andere Frage. +1

— user179700

@ user179700: Ich hoffe derzeit, ein Skript zu schreiben, mit dem Sie eine Festschreibungsnachricht ändern können, jedoch nur durch Hinzufügen einer zusätzlichen Zeichenfolge mit Zeitstempel. So können Sie Fehler korrigieren und gleichzeitig den Audit-Trail beibehalten.

— Tynam