Огляд + питання

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

Хто-небудь може запропонувати будь-які поради / рекомендації / робочі рішення, щоб надати одне або обидва з наступного:

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

Детальніше, фон

Зростає інтерес до розширення git із можливостями управління файловою системою та метаданими . Метадані " etc Engine" метадані здаються досить потужними та надійними в моєму досвіді, і etckeeper здається популярним і для інших . metastore в меншій мірі, по крайней мере , частково з - за нетекстової основою / злиття недружніх проблем metastore в . Далі, тощо, схоже, розпочали з основи метасторів, але потім перейшли до своєї власної (умоглядної?).

Очевидно, що це має особливості ОС / файлової системи. (наприклад, не намагаються автоматично розгортатись у Windows.) Запропонуйте необов’язковорозширення (якщо це "нативне розширення") git, увімкнене на вимогу користувача з зрозумілими наслідками поломки між платформами, таким чином, щоб нативна поведінка не порушувала "за замовчуванням" дружелюбність крос-платформи. Крім того, не потрібно зберігати екстравагантні метадані unix / darwin / тощо (як ACL); базовий користувач / група / інші особи та власник користувача / групи буде добре. (Це єдині речі, які в даний час руйнують речі в моїй "контролі / політиці безпеки та вразливості".) Конкретні ОС, на які я націлююся вперед: Debian, Ubuntu, MacOS 10.6+. Пізніше: Redhat (CentOS, Fedora, RHEL), SUSE, можливо інші Linuxes, та * BSD (FreeBSD, NetBSD, OpenBSD). Не бачите потреби / програми для Windows / VMS (навіть незважаючи на те, що VMS може бути зручним для позицій) або інших ОС, не схожих на Unix, у будь-який передбачуваний момент.

Дивіться також: передумови щодо попередньо існуючих можливостей git, метаданих файлів / файлів для відстеження типу цього питання щодо stackoverflow, яке я опублікував .

Розвивати вимоги до нового проекту?

Додатково: якщо хтось піклується про розробку вимог до таких можливостей, я впевнений, що це може виявитися корисним, особливо для нового / незавершеного проекту, на який звертатися вище.

Відповідно до цієї серверної відповіді , ви просто так:

Це прямо там, на сторінці man .

• Створіть каталог /foo
• Ініціалізуйте з etckeeper: etckeeper -d /foo init
• Коміти застосовують до каталогу: etckeeper -d /foo commit 'message'

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

git-store-meta - це сценарій perl, який об'єднує приємні риси git-cache-meta, metastore, setgitperms та mtimestore. Це повинно слугувати хорошим компромісом щодо гнучкості, функціональності, продуктивності та портативності та послідовності між платформами.