Ich bin nicht sehr vertraut mit Git, aber es sieht aus wie es Filterattribute verwenden kann, um beispielsweise XML-Dateien vor dem Commit sauber zu machen. Das SVN-Handbuch rät ausdrücklich (und ausdrücklich) davon ab, Pre-Commit Hooks dafür zu verwenden. Gibt es eine andere Art und Weise?Kann SVN so etwas wie Git Filterattribute tun?
Die Antwort darauf scheint zu sein: nein. Ich glaube, dass die Ablehnung des Commits die einzige sichere Option mit SVN ist.
Es gibt keinen anderen Weg es zu tun, und Sie werden feststellen, dass das, wenn Sie so etwas tun, selbst wenn es unterstützt wird, Ihnen nur Kopfschmerzen bereiten wird. Selbst das Neuformatieren des Codes vor dem Einchecken wird nicht empfohlen, da Ihre Revisions-Diffs Ihnen kein gutes Bild davon geben, was sich wirklich geändert hat. Ich mache es nur, wenn etwas so schrecklich formatiert ist, dass es nicht lesbar ist.
Dies ist kein Problem. Es ist keine einmalige Operation, die Formatierung der Dateien auf eine Weise zu ändern, die mit der VCS-Historie interferiert. Die Dateien sind schon ziemlich gut in Form, aber der Punkt ist, sie so zu halten. –
Der einzige Ort, an dem Sie so etwas tun möchten, ist die Verwendung von clean/smudge Skripts, um Ihre Datenbankverbindungszeichenfolge, das Passwort für ein Commerce-Portal usw. zu verschleiern. Dies wird normalerweise getan, wenn Sie eine Konfigurationsdatei haben können Mix aus funktionalen öffentlichen Daten und privaten Sicherheitsdaten.
Pro Git Book's Attributes Section
Hoffnung, das hilft.
Meine Frage bezieht sich auf SVN. Und es gibt andere Gründe, dies zu tun. –
Das klingt nach einem Job für Ihren IDE- oder XML-Editor. Eclipse zum Beispiel lässt Sie verschiedene automatische Aktionen beim Speichern angeben (aber macht einen schlechten XML-Editor) ... Ich bin mir sicher, dass es einen XML-Editor gibt, der Ihre XML für Sie beim Speichern aufräumt oder neu formatiert.
Ich glaube nicht, Diffs sollte ein Grund dagegen sein, weil ein gutes Diff-Tool Optionen zum Ignorieren Leerzeichen und/oder unbedeutende Unterschiede haben wird, die Anzeige der Diffs einfach, auch wenn eine Datei neu formatiert wurde.
Je nachdem, mit welchem Team Sie arbeiten, und wenn dieses "Aufräumen" jede Datei, die Sie berühren, dramatisch verändert, möchten Sie es vielleicht vermeiden oder es könnte vollkommen in Ordnung sein. Ich habe zum Beispiel Eclipse Trim Trailing Whitespace trimmen und fehlende @Override Annotationen beim Speichern hinzufügen, aber ich sage nicht, meine .java-Dateien beim Speichern vollständig neu zu formatieren.
Es gibt Leute, die mehrere verschiedene Editoren verwenden, und es wird auch eine automatische Verarbeitung durchgeführt. Im Allgemeinen werden die Dateien nicht dramatisch verändert, aber es ist erforderlich, sie auf Team-Standards zu halten. –
Hmm. In diesem Fall kann es als Teil der automatisierten Verarbeitung durchgeführt werden? Das oder vielleicht haben Devs manuell ein XML-Bereinigungsskript außerhalb ihres Editors ausgeführt. Auch wenn Entwickler verschiedene Editoren verwenden, ist es nicht möglich, jeden Editor entsprechend zu konfigurieren, so dass dies kein Problem ist? –
Mit Git haben Sie eine vollständige Kopie des Repository für Ihren persönlichen Gebrauch, so dass Munging Dateien während eines Commits sie kein Problem ist. Schließlich betrügst du dich nur selbst.
Subversion verfügt jedoch über ein zentralisiertes Repository, was bedeutet, dass das Verschieben von Dateien während eines Commits schwieriger ist und normalerweise nicht empfohlen wird.
Eines der Probleme ist, dass diese Art von Sache von einem Haken behandelt werden muss, und Hooks, da sie auf dem Server ausgeführt werden, haben keinen Zugriff auf Ihre Arbeitskopie. Sie können das Commit über den schreibgeschützten Befehl svnlook untersuchen, aber das war's. Ja, es gibt Möglichkeiten, um es zu umgehen, aber wie das Handbuch sagte, ist es nicht zu empfehlen.
Selbst mit Versionskontrollsystemen wie Git und ClearCase, wo es möglich ist, Dateien während eines Commits zu munge, ist es immer noch keine gute Idee. Erstens kann es den Festschreibungsprozess verlangsamen, wenn das Hook-Skript ausgeführt wird, was den Benutzer frustrieren kann. Zweitens, was passiert, wenn der Mungprozess die Datei tatsächlich bricht? Entwickler sollten ihre Änderungen testen und verifizieren, bevor sie sie übernehmen. "Breaking a build" ist ein Verbrechen noch schlimmer als die letzte Tasse Kaffee im Pausenraum zu nehmen und keinen weiteren Topf zu machen. Aber hier ist ein Entwickler, der alles gemacht hat, was er erwartet hat, und es war das dumme Hook-Skript, das es getan hat!
Dies sollte durch den automatisierten Build-Prozess erfolgen (Sie verwenden ein inkrementelles Build-System wie CruiseControl oder Hudson richtig?).Dies kann als Teil des Tests durchgeführt werden, und der Build kann als "instabil" markiert werden, wenn die Datei nicht korrekt formatiert ist. In der Tat hat Hudson Haken, die dies als Teil des Build-Prozesses tun können, was dies sehr einfach macht. Der Build-Server kann den Programmierer über seine Missetaten (schlechter Programmierer! Die Datei ist schlecht eingerückt! Kein Donut für Sie!) Und den technischen Leiter oder den Build-Manager benachrichtigen.
Was eingecheckt wird, ist was der Entwickler geschrieben und getestet hat. Über das Build-System können Sie nach Formatierungen, Komponententests und all den anderen Dingen suchen.
Im konkreten Fall bin ich besorgt, dass es kein Build-System gibt: es sind Konfigurationsdaten. Wir möchten nicht, dass beschädigte Konfigurationsdaten jemals das Repository erreichen, da anderen Mitarbeitern die Gelegenheit gegeben wird, diese Konfiguration zu implementieren. Es gibt Staging-Umgebungen, aber es gibt auch eine große Anzahl scheinbar harmloser Veränderungen und Zeitdruck. Die Wahrscheinlichkeit von manuellen Fehlern ist viel größer als die Wahrscheinlichkeit eines Bugs in "ordentlich". Commit-Geschwindigkeit ist kein Problem. Zu einem späteren Zeitpunkt werden die Bereitstellungstools diese Überprüfung durchführen, was wahrscheinlich die richtige Lösung ist. –
Denken Sie daran, dass Sie eine Änderung in einem Versionskontrollsystem jederzeit rückgängig machen können. Sie können einschränken, wer was einchecken darf. Ich habe einen Haken, mit dem Sie das konfigurieren können, was Sie von [hier] herunterladen können (http://dl.dropbox.com/u/433257/hook.tgz). Auf diese Weise können Sie verhindern, dass Personen versehentlich Änderungen vornehmen. Wenn Sie wirklich möchten, erstellen Sie einen Vorab-Auslöser, und erstellen Sie einen, der die Transaktion einfach ablehnt, wenn die Datei nicht korrekt formatiert ist. Entwickler werden schnell lernen, das Format zu verifizieren, bevor sie es tun. –
+1 Ja. Nein das ist. –