Обзор + вопрос

Мне нужен контроль метаданных файловой системы, подобный etckeeper, для не / etc, каталогов, контролируемых git. Домашние каталоги и каталоги веб-приложений, среди прочего, классически чувствительны к метаданным (владение файлами, ACL, разрешения). Это может быть чрезвычайно полезно / важно для использования git для автоматического развертывания сервера (наряду с такими инструментами, как Fabric ), между прочим. Я хотел бы повторно использовать возможность, подобную etckeeper, на указанных каталогах, либо с самим etckeeper, либо с чем-то еще.

Может кто-нибудь предложить какие-либо советы / хитрости / рабочие решения, чтобы обеспечить одно или оба из следующих:

1. примените механизм etckeeper (заботитесь только о специфичных для git возможностях etckeeper) к каталогам, не относящимся к / etc, и контролируемым git. (Можно предположить, по крайней мере, Debian / Ubuntu Linux; хотелось бы поддержки MacOSX / homebrew, если это возможно.)
2. расширить поддержку git с помощью метаданных (помимо чрезмерно упрощенных вещей, таких как git-cache-meta ) для поддержки возможности, подобной etckeeper, или лучше?

Подробнее, фон

Растет интерес к расширению git с помощью возможностей управления метаданными файловой системы . По моему опыту, «движок» метаданных etckeeper кажется достаточно мощным и надежным, и etckeeper, похоже, популярен и среди других . metastore меньше, по крайней мере, частично из-за нетекстовых проблем / недопущения слияния metastore . Кроме того, etckeeper, похоже, начал с ядра на основе метастазов, но затем переключился на свое собственное (спекулятивное?).

Очевидно, что это зависит от ОС / файловой системы. (например, не пытаться автоматически развертывать в Windows.) Предложите дополнительныйрасширение (если это «собственное расширение») git, включаемое пользователем по требованию с понятными последствиями кросс-платформенной поломки, так что нативное поведение не нарушает кроссплатформенность git по умолчанию. Кроме того, не нужно сохранять экстравагантные метаданные unix / darwin / etc (например, ACL); базовый пользователь / группа / другие привилегии и владелец пользователя / группы будет в порядке. (Это единственные вещи, которые в настоящее время ломают вещи в моем «контроле / политике безопасности / уязвимостей».) Конкретные ОС, на которые я нацеливаюсь заранее: Debian, Ubuntu, MacOS 10.6+. Позже: Redhat (CentOS, Fedora, RHEL), SUSE, возможно, другие Linux, и * BSD (FreeBSD, NetBSD, OpenBSD). Не вижу необходимости / приложения для Windows / VMS (даже если VMS может быть удобной для posix) или других не-unix-подобных ОС в любой обозримой точке.

См. Также: справочная информация о ранее существовавшем git, возможности отслеживания метаданных файлов / типов файлов в этом вопросе о стековом потоке, который я разместил .

Разработать требования для нового проекта?

Дополнительно: если кто-то захочет разработать требования для такой возможности, я уверен, что это может оказаться полезным, особенно для нового / незавершенного проекта, о котором говорилось выше.

Согласно этому ответу сервера , вы просто делаете это:

Это прямо на странице руководства .

• Создать каталог /foo
• Инициализировать с помощью etckeeper: etckeeper -d /foo init
• Commit применяет коммиты в каталог: etckeeper -d /foo commit 'message'

Я копался в этой проблеме и решил создать для нее проект git-store-meta .

git-store-meta - это Perl-скрипт, который объединяет в себе приятные функции git-cache-meta, metastore, setgitperms и mtimestore. Он должен служить хорошим компромиссом в отношении гибкости, функциональности, производительности и межплатформенной переносимости и согласованности.