Panoramica + domanda

Voglio il controllo dei metadati del filesystem simile a etckeeper per directory non-/ etc, controllate da git. Le directory delle home e delle web app, tra le altre, sono classicamente sensibili ai metadati (proprietà dei file, ACL, permessi). Questo può essere estremamente utile / importante utilizzare git per la distribuzione automatica dei server (insieme a strumenti come tessuto ), tra le altre cose. Vorrei riutilizzare la capacità di etckeeper su detti dirs, sia con etckeeper stesso o qualcos'altro.

Qualcuno può suggerire suggerimenti / trucchi / soluzioni di lavoro per fornire uno o entrambi i seguenti:

1. applica il motore etckeeper (preoccupati solo della capacità specifica di git di etckeeper) su directory non controllate da / / etc, git. (Può assumere almeno Debian / Ubuntu Linux; se possibile , vorrebbe il supporto per MacOSX / homebrew .)
2. estendere git con il supporto dei metadati (oltre a cose troppo semplificate come git-cache-meta ) per supportare una capacità simile a quella di etckeeper o meglio?

Maggiori dettagli, sfondo

C'è un crescente interesse nell'estensione di git con funzionalità di controllo dei metadati del filesystem . Il "motore" dei metadati di etckeeper sembra abbastanza potente e affidabile nella mia esperienza, e etckeeper sembra popolare anche con gli altri . metastore meno , almeno in parte, a causa delle sfide non testuali / non ostili di metastore . Inoltre, etckeeper sembra aver iniziato con un core basato su metastore, ma poi è passato al suo (speculativo?).

Ovviamente, questo ha dipendenze specifiche del SO / filesystem. (ad esempio, non tentare di eseguire la distribuzione automatica su Windows.) Suggerisci un facoltativoestensione (se si tratta di una "estensione nativa") di git, abilitata su richiesta dall'utente con implicate conseguenze di un'interruzione multipiattaforma, in modo tale che il comportamento nativo non interrompa la compatibilità "per impostazione predefinita" tra piattaforme di git. Inoltre, non è necessario salvare stravaganti metadati unix / darwin / etc (come gli ACL); gli utenti di base / gruppo / altri permanenti e la proprietà dell'utente / gruppo andrebbero bene. (Queste sono le uniche cose che attualmente stanno rompendo le cose nel mio "controllo / criteri di sicurezza / vulnerabilità"). Sistemi operativi specifici che sto prendendo di mira in anticipo: Debian, Ubuntu, MacOS 10.6+. Più tardi: Redhat (CentOS, Fedora, RHEL), SUSE, forse altri Linux e * BSD (FreeBSD, NetBSD, OpenBSD). Non vedere un'esigenza / applicazione per Windows / VMS (anche se VMS può essere posix-friendly) o altri sistemi operativi non unix-like in qualsiasi punto prevedibile.

Vedi anche: informazioni sulle funzionalità di tracciamento git, metadati / tipo file preesistenti in questa domanda di StackOverflow che ho pubblicato .

Sviluppare i requisiti per un nuovo progetto?

Inoltre: se qualcuno si preoccupa di sviluppare requisiti per tale capacità, sono sicuro che potrebbe rivelarsi utile, in particolare per un progetto nuovo / non completato da affrontare in precedenza.

In base a questa risposta predefinita del server , è sufficiente:

È proprio lì nella pagina man .

• Crea una directory /foo
• Inizializza con etckeeper: etckeeper -d /foo init
• Commit Apply esegue il commit nella directory: etckeeper -d /foo commit 'message'

Ho risolto questo problema e ho deciso di creare un progetto git-store-meta per questo.

git-store-meta è uno script perl che integra le belle funzionalità di git-cache-meta, metastore, setgitperms e mtimestore. Dovrebbe servire un buon compromesso tra flessibilità, funzionalità, prestazioni, portabilità e coerenza multipiattaforma.