Comment réutiliser / étendre le moteur de métadonnées de etckeeper pour le contrôle git des systèmes de fichiers non / etc, ou étendre git nativement avec cette capacité?


16

Aperçu + question

Je veux un contrôle des métadonnées du système de fichiers semblable à etckeeper pour les répertoires non / etc, contrôlés par git. Les répertoires personnels et d'applications Web, entre autres, sont classiquement sensibles aux métadonnées (propriété des fichiers, ACL, autorisations). Cela peut être extrêmement utile / important pour utiliser git pour le déploiement de serveur automatisé (avec des outils comme Fabric ), entre autres. Je voudrais réutiliser la capacité de type etckeeper sur lesdits répertoires, soit avec etckeeper lui-même ou autre chose.

Quelqu'un peut-il suggérer des conseils / astuces / solutions de travail pour fournir l'un ou les deux des éléments suivants:

  1. appliquer le moteur etckeeper (ne vous souciez que des capacités spécifiques à git de etckeeper) aux répertoires non / etc, contrôlés par git. (Peut supposer au moins Debian / Ubuntu Linux; aimerait le support MacOSX / homebrew si possible.)
  2. étendre git avec la prise en charge des métadonnées (au-delà de choses trop simplifiées comme git-cache-meta ) pour prendre en charge une capacité similaire à celle de etckeeper ou mieux?

Plus de détails, arrière-plan

Il y a un intérêt croissant pour étendre git avec des capacités de contrôle des métadonnées du système de fichiers . Le "moteur" de métadonnées de etckeeper semble assez puissant et fiable dans mon expérience, et etckeeper semble également populaire auprès des autres . metastore moins donc au moins en partie en raison des défis non basés sur le texte / hostile de fusion de metastore . De plus, etckeeper semble avoir commencé avec un noyau basé sur les métastores, mais est ensuite passé au sien (spéculatif?).

Évidemment, cela a des dépendances spécifiques au système d'exploitation / fichiers. (par exemple, ne pas essayer de se déployer automatiquement sous Windows.) Suggérer une optionextension (s'il s'agit d'une "extension native") de git, activée à la demande par l'utilisateur avec les conséquences comprises de la rupture multiplateforme, de sorte que le comportement natif ne rompt pas la convivialité multiplateforme "par défaut" de git. De plus, vous n'avez pas besoin de sauvegarder les métadonnées extravagantes unix / darwin / etc (comme les ACL); l'utilisateur / groupe / autres autorisations de base et la propriété de l'utilisateur / groupe serait bien. (Ce sont les seules choses qui cassent actuellement les choses dans mon "sécurité / contrôle des vulnérabilités / politiques".) OS spécifiques que je cible en premier: Debian, Ubuntu, MacOS 10.6+. Plus tard: Redhat (CentOS, Fedora, RHEL), SUSE, peut-être d'autres Linux et * BSD (FreeBSD, NetBSD, OpenBSD). Ne voyez pas un besoin / une application pour Windows / VMS (même si VMS peut être compatible avec Posix) ou d'autres systèmes d'exploitation non-Unix à tout moment prévisible.

Voir aussi: informations sur git préexistant, capacités de suivi des métadonnées / types de fichiers à cette question de stackoverflow que j'ai publiée .

Développer des exigences pour un nouveau projet?

De plus: si quelqu'un souhaite développer des exigences pour une telle capacité, je suis sûr que cela pourrait s'avérer utile, en particulier pour un projet nouveau / inachevé à traiter ci-dessus.



Vous pourriez probablement accomplir cela en utilisant des hooks git (potentiellement sophistiqués) .
Justin

Crochets personnalisés: à droite, comme avec git-cache-meta comme mentionné ci-dessus; utile, mais une solution trop simplifiée. Hélas, cherchant à "pousser" cette fonctionnalité au-delà des crochets personnalisés par l'utilisateur dans quelque chose de "communautaire" pour une meilleure fonctionnalité / fiabilité / fonctionnalités / codereview / etc. De plus, je ne veux pas l'écrire à partir de zéro, du moins pas par moi-même.
Johnny Utahh


Des mises à jour ici?
cregox

Réponses:


4

Selon cette réponse de défaut de serveur , vous faites simplement ceci:

C'est juste là dans le page de manuel .

  • Créer un annuaire /foo
  • Initialisez avec etckeeper: etckeeper -d /foo init
  • Valider appliquer valide le répertoire: etckeeper -d /foo commit 'message'

Plutôt interessant. Je ne trouve aucun port / test etckeeper fonctionnant sur Mac OS X. Rien dans l'homebrew ni nulle part ailleurs substantiel. Quelqu'un sait quelque chose?
Johnny Utahh

Je demande les suggestions de etckeeper pour le portage de Mac OS X ici: joeyh.name/code/etckeeper/discussion
Johnny Utahh

@JohnnyUtahh: il ne semble pas y avoir eu de réponse de Joey ou de quelqu'un d'autre ... avez-vous fait des progrès sur un port OS X?
iconoclaste

@JohnnyUtahh: au fait, j'ai trouvé ceci: github.com/myint/etckeeper
iconoclast

@iconoclast Je n'ai fait aucun travail vers un port OS X, ni aucun travail sur ce projet, d'ailleurs. github.com/myint/etckeeper semble utile - merci!
Johnny Utahh

4

J'ai creusé ce problème et j'ai décidé de créer un projet git-store-meta pour cela.

git-store-meta est un script perl qui intègre les fonctionnalités intéressantes de git-cache-meta, metastore, setgitperms et mtimestore. Il doit servir un bon compromis entre la flexibilité, la fonctionnalité, les performances, la portabilité et la cohérence multiplateforme.


Je n'ai pas encore trouvé le temps de tester et de réviser git-store-meta, mais à première vue, il semble approfondi et très prometteur. Très apprécié. J'ai très hâte de tester cela. Merci encore, @Danny Lin.
Johnny Utahh

@ 'Danny Lin', j'ai référencé git-store-meta à ma question connexe, stackoverflow .
Johnny Utahh

Mon point de vue: cette solution (git-store-meta) est meilleure que l'utilisation abusive de etckeeper.
guettli

Mise à jour: Je viens de regarder sur la README.md à git magasin-meta , et il semble grand . Je suis impatient de me faire essayer, moi ou un membre de mon équipe, la prochaine fois que nous en aurons.
Johnny Utahh
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.