Przegląd + pytanie

Chcę kontroli metadanych systemu plików podobnego do etckeepera dla katalogów nie / etc, kontrolowanych przez git. Domowe i katalogi aplikacji internetowych są między innymi klasycznie wrażliwe na metadane (własność pliku, ACL, uprawnienia). Może to być bardzo przydatne / ważne, aby zastosować git do zautomatyzowanego wdrażania serwera (wraz z narzędziami takimi jak Fabric ). Chciałbym ponownie użyć funkcji przypominającej etckeeper na wspomnianych katalogach, albo z samym etckeeper, albo z czymś innym.

Czy ktoś może zasugerować jakieś wskazówki / triki / działające rozwiązania, aby zapewnić jedno lub oba z poniższych:

1. zastosuj silnik etckeeper (dbaj tylko o specyficzne dla git możliwości etckeeper) do katalogów nie / etc, kontrolowanych przez git. (Można założyć przynajmniej Debian / Ubuntu Linux; chciałby, jeśli to możliwe, obsługi MacOSX / homebrew ).
2. rozszerzyć git o obsługę metadanych (poza zbyt uproszczonymi rzeczami, takimi jak git-cache-meta ), aby obsługiwać funkcje podobne do etckeeper czy lepiej?

Więcej szczegółów, tło

Rośnie zainteresowanie rozszerzeniem gita o funkcje kontroli metadanych systemu plików . „silnik” metadanych etckeepera wydaje mi się dość mocny i niezawodny z mojego doświadczenia, a etckeeper wydaje się popularny również wśród innych . mniej przerzutów, a przynajmniej częściowo ze względu na nieoparte na tekście / nieprzyjemne dla metastore wyzwania . Co więcej, wydaje się, że etckeeper zaczął od rdzenia opartego na metastore, ale następnie przeszedł na swój własny (spekulacyjny?).

Oczywiście ma to specyficzne dla OS / systemu plików zależności. (np. nie próbuje się automatycznie wdrażać w systemie Windows.) Zasugeruj opcjonalnerozszerzenie (jeśli jest to „natywne rozszerzenie”) git, włączone przez użytkownika na żądanie ze zrozumiałymi konsekwencjami awarii międzyplatformowej, tak że natywne zachowanie nie psuje „domyślnie” przyjazności dla wielu platform git. Ponadto nie trzeba zapisywać ekstrawaganckich metadanych unix / darwin / etc (takich jak ACL); podstawowe prawa użytkownika / grupy / inne uprawnienia i własność użytkownika / grupy byłyby w porządku. (Są to jedyne rzeczy, które obecnie psują się w moich „zabezpieczeniach / kontroli podatności / politykach”.) Określone systemy operacyjne, na które celuję z góry: Debian, Ubuntu, MacOS 10.6+. Później: Redhat's (CentOS, Fedora, RHEL), SUSE, może inne Linuxes i * BSD (FreeBSD, NetBSD, OpenBSD). Nie widzę potrzeby / aplikacji dla Windows / VMS (nawet jeśli VMS może być przyjazny dla posiksów) lub innych nie-uniksowych systemów operacyjnych w dowolnym przewidywalnym momencie.

Zobacz także: tło na temat wcześniejszych możliwości śledzenia gita, metadanych / typów plików w odpowiedzi na to pytanie dotyczące przepływu stosów .

Opracować wymagania dla nowego projektu?

Dodatkowo: jeśli komuś zależy na opracowaniu wymagań dotyczących takich możliwości, jestem pewien, że może się to okazać przydatne, szczególnie w przypadku nowego / niezakończonego projektu, o którym mowa powyżej.

Zgodnie z odpowiedzią na błąd serwera wystarczy wykonać następujące czynności:

Jest tam na stronie man .

• Utwórz katalog /foo
• Zainicjuj za pomocą etckeeper: etckeeper -d /foo init
• Zatwierdź zastosuj zatwierdzenia do katalogu: etckeeper -d /foo commit 'message'

Wkopałem się w ten problem i postanowiłem stworzyć dla niego projekt git-store-meta .

git-store-meta to skrypt perla, który integruje ładne funkcje git-cache-meta, metastore, setgitperms i mtimestore. Powinno to stanowić dobry kompromis w zakresie elastyczności, funkcjonalności, wydajności oraz przenośności i spójności między platformami.