개요 + 질문
나는 / etc가 아닌 git-controlled 디렉토리에 대한 etckeeper 와 같은 파일 시스템 메타 데이터 제어를 원합니다 . 홈 및 웹앱 디렉토리는 특히 메타 데이터 (파일 소유권, ACL, 권한)에 민감합니다. 이는 Fabric 과 같은 도구와 함께 자동화 된 서버 배포 를 위해 git을 사용하는 데 특히 유용하고 중요 할 수 있습니다 . 나는 etckeeper 자체 또는 다른 것과 함께 상기 디렉토리에서 etckeeper와 같은 기능을 재사용하고 싶습니다.
누구나 다음 중 하나 또는 둘 다를 제공하기위한 팁 / 트릭 / 작업 솔루션을 제안 할 수 있습니까?
- etckeeper 엔진 (etckeeper의 git 특정 기능에만주의)을 git-controlled 디렉토리에 적용하십시오. (적어도 Debian / Ubuntu Linux를 가정 할 수 있으며 가능하면 MacOSX / homebrew 지원을 원합니다 .)
- 메타 키퍼 지원 ( git-cache-meta 와 같이 지나치게 단순화 된 것 이외)으로 git을 확장 하여 etckeeper와 같은 기능을 지원합니까?
자세한 내용, 배경
filesystem-metadata-control 기능으로 git을 확장 하는 것에 대한 관심이 커지고 있습니다 . etckeeper의 메타 데이터 “engine”은 제 경험상 상당히 강력하고 신뢰할 수있는 것처럼 보이며 etckeeper는 다른 사람들에게도 인기가 있습니다 . 메타 스토어의 비 텍스트 기반 / 병합 친화적이지 않은 도전 으로 인해 메타 스토어가 최소한 부분적으로 줄어 듭니다 . 또한 etckeeper는 메타 스토어 기반 코어로 시작한 다음 자체 (추론?)로 전환 한 것으로 보입니다.
분명히 이것은 OS / 파일 시스템에 따라 다릅니다. (예 : Windows에서 자동 배포를 시도하지 않음) 옵션 제안git의 extension ( “네이티브 확장”인 경우), 사용자가 플랫폼 간 파손의 결과를 이해할 수있게하여 기본 동작이 git의 “기본”크로스 플랫폼 친 화성을 깨뜨리지 않도록 사용자가 주문형으로 활성화 할 수 있습니다. 또한 ACL과 같은 화려한 유닉스 / 다윈 / 등 메타 데이터를 저장할 필요가 없습니다. 기본 사용자 / 그룹 / 기타 권한 및 사용자 / 그룹 소유권이 좋습니다. (이것은 현재 “보안 / 취약점 통제 / 정책”에서 문제를 일으키는 유일한 것입니다.) 내가 목표로 삼고있는 특정 OS : 데비안, 우분투, MacOS 10.6+. 나중에 : Redhat (CentOS, Fedora, RHEL), SUSE, 다른 Linux 및 * BSD (FreeBSD, NetBSD, OpenBSD). 예측 가능한 시점에서 Windows / VMS에 대한 요구 / 응용 프로그램 (VMS는 posix 친화적 일 수 있음) 또는 기타 유닉스와 유사한 OS를 보지 마십시오.
참고 : 내가 게시 한이 stackoverflow 질문 에서 기존 git, 파일 메타 데이터 / 파일 유형 추적 기능에 대한 배경 지식 .
새로운 프로젝트에 대한 요구 사항을 개발 하시겠습니까?
또한 누군가가 그러한 기능에 대한 요구 사항을 개발하려는 경우 특히 위의 새 / 미완료 프로젝트에 유용 할 것으로 확신합니다.
답변
이 serverfault answer 에 따르면 다음과 같이 하면됩니다.
그것은 바로이 사람 페이지 .
- 디렉토리 만들기
/foo- etckeeper로 초기화하십시오.
etckeeper -d /foo init- 커밋은 디렉토리에 커밋을 적용합니다.
etckeeper -d /foo commit 'message'
답변
나는이 문제를 파고 그것을 위해 git-store-meta 프로젝트를 만들기로 결정 했다.
git-store-meta는 git-cache-meta, metastore, setgitperms 및 mtimestore의 멋진 기능을 통합 한 perl 스크립트입니다. 유연성, 기능성, 성능 및 플랫폼 간 이식성과 일관성의 절충을 제공해야합니다.