Gibt es eine Möglichkeit, beim Erstellen von Repositories einen benutzerdefinierten Commit-Hook als „Standard“-Hook festzulegen?
Antwort1
Abgesehen von den neun Standard-Hooks, die mit dem Befehl „svnadmin create /path/to/repo“ in einem neuen Repository installiert werden (start-commit, pre/post-commit, pre/post-revprop-change, pre/post-lock und pre/post-unlock), ist mir keine Möglichkeit bekannt, zusätzliche Hooks automatisch als „Standard“-Hook für alle neu erstellten Repositories einzubinden.
Ich nehme an, Sie könnten ein Wrapper-Shell-Skript zum Erstellen neuer Repositories erstellen, das den Befehl „svnadmin create“ mit einer für den Repository-Pfad festgelegten Variablen aufruft, gefolgt von einem Kopieren des benutzerdefinierten Commit-Hooks in den Ordner „path/to/repo/hooks“ und das dann für alle neuen Repositories verwendet.
Da Sie erwähnen, dass es sich bei diesem benutzerdefinierten Hook insbesondere um einen Commit-Hook handelt, sollte ich die Warnung von wiederholenVersionskontrolle mit Subversionbei der DiskussionHook-Skripte(Hervorhebung von mir):
Obwohl Hook-Skripte fast alles können, gibt es eine Dimension, in der Hook-Skript-Autoren Zurückhaltung üben sollten:Ändern Sie keine Commit-Transaktionen mithilfe von Hook-Skripten.. Es mag zwar verlockend sein, Hook-Skripte zu verwenden, um Fehler, Mängel oder Richtlinienverletzungen in den zu committenden Dateien automatisch zu korrigieren, aber dies kann zu Problemen führen. Subversion speichert clientseitige Caches bestimmter Teile der Repository-Daten, und wenn Sie eine Commit-Transaktion auf diese Weise ändern, veralten diese Caches unmerklich. Diese Inkonsistenz kann zu überraschendem und unerwartetem Verhalten führen. Anstatt die Transaktion zu ändern, sollten Sie die Transaktion einfach im Pre-Commit-Hook validieren und das Commit ablehnen, wenn es die gewünschten Anforderungen nicht erfüllt. Als Bonus lernen Ihre Benutzer den Wert sorgfältiger, konformitätsorientierter Arbeitsgewohnheiten kennen.