Re: Konfigurationsmanagement via VCS / etckeeper
Martin Steigerwald <Martin@lichtvoll.de> wrote:
> Am Wednesday 20 April 2011 schrieb Sven Hartge:
>> Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
>>> On Sat, 2 Apr 2011 15:41:48 +0200, Sven Hartge <sven@svenhartge.de> wrote:
>> >> Vorteil von etckeeper: In den Workflow von Debian integriert, so
>> >> dass man nichts manuell machen muss.
>> >
>> > Wie ist denn der Workflow von Debian beim Bearbeiten von Files
>> > innerhalb von /etc?
>>
>> Ich meinte damit: Klinkt sich via /etc/apt.conf.d/ in den
>> Paketmanager ein und kann somit durch entsprechende Hooks
>> automatische Commits vornehmen, wenn Pakete de/installiert werden.
> Genau den Teil kapiere ich nicht: Soweit ich hier raus las, legt es
> etckeeper darauf an, bis auf einige ignorierte Dateien *alle* Dateien
> in das VCS einzuchecken?
> Wozu?
Wozu nicht?
> Ich mach einfach ein bzr init und füge dann nur die Dateien dazu, die
> ich auch *ändere*. Wenn ich dann mit bzr branch einen Branch anlege,
> hab ich übersichtlich nur das, wo ich auch hingefasst habe. Ich nehme
> außerdem Dateien dann mit bzr remove --keep aus dem VCS heraus, wenn
> ich meine Anpassungen daran zurücknehme.
> Oder andersherum: Was zum Geier interessieren mich die
> Konfigurationsdateien, die ich *nie* angefasst hab?
Nicht nur du fast Konfig-Files an, auch der Paketmanager macht dies. Das
möchte zumindest ich auch rückverfolgt wissen.
> Für die Dateien, die mich interessieren, informiert mich bzr diff über
> Änderungen nach einem Paket-Upgrade. Das hätte ich vielleicht ganz
> gerne integriert. Aber wenn ich alle Dateien einchecke, dann bekomme
> ich ja auch Commits für Änderungen von Dateien, die mich gar nicht
> interessieren. Wie soll ich da auf einfache Weise noch herausfinden,
> was ich an welchen Dateien selbst geändert habe und was der
> Maintainer? Unterscheidet etckeeper diese beiden Fälle?
Wenn du eine Änderung machst, dann rufst du selbst
etckeeper commit 'blafasel geändert weil laber sülz'
auf. Wenn der Paket-Manager etwas ändert und eincheckt, dann gibt es
eine generische Log-Meldung.
Ehrlich gesagt, sehe ich dein Problem nicht, was du mit der
Vorgehensweise hast.
> Ganz ehrlich, ich kapier den Sinn dahinter nicht, alle Dateien
> einzuchecken.
Warum nicht? Belegt kaum Platz und erfasst alles. Keine Datei aus
versehen übersehen, weil man vergessen hat, sie hinzuzufügen.
Fire and forget.
Ich liebe solche Lösungen, die mir a) nicht im Weg stehen und b) im
Hintergrund still ihre arbeit machen, ohne das ich c) dauernd an sie
denken muss.
Kein Problem, wenn du für dich eine andere Arbeitsweise etabliert hast,
die für dich funktioniert.
S°
--
Sigmentation fault. Core dumped.
Reply to: