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.

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'

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.