홈 디렉토리 관리를 위한 최고의 버전 관리 시스템

StackOverflow https://stackoverflow.com/questions/38362

  •  09-06-2019
  •  | 
  •  

문제

저는 3개의 Linux 시스템을 가지고 있으며 해당 시스템의 홈 디렉터리에 있는 도트 파일을 동기화 상태로 유지할 수 있는 방법을 원합니다..vimrc와 같은 일부 파일은 3개 시스템 모두에서 동일하고 일부는 각 시스템마다 고유합니다.

이전에 SVN을 사용해 본 적이 있지만 DVCS에 대한 모든 소문 때문에 한번 사용해 봐야겠다는 생각이 들었습니다. 이것에 가장 잘 맞는 특별한 것이 있습니까?아니면 SVN을 계속 사용해야 할까요?

도움이 되었습니까?

해결책

나는 같은 문제를 겪었고 Subversion 위에 권한, 소유권 및 secontext 추적을 추가하고 .svn 디렉토리를 실제로 버전이 지정된 트리에서 제외하고 레이어 개념을 추가하는 도구를 구축했습니다. 개발과 관련된 구성은 개발에 사용하는 컴퓨터에서만 확인할 수 있습니다.

이는 내가 로그인하는 50개 이상의 컴퓨터에서 내 설정을 훨씬 더 효과적으로 구성하는 데 도움이 되었습니다.

프로젝트 페이지는 여기.여전히 가장자리가 약간 거칠지만 직장에서 60개 이상의 서버에 대한 시스템 구성 버전을 지정하는 데에도 사용합니다.

일반적으로 일종의 메타데이터 파일을 사용하여 내용을 추적하는 버전 제어 시스템은 실제로 사용할 때와 마찬가지로 어려움을 겪게 됩니다.

다른 팁

나는 수년 동안 이 문제를 겪었고 버전 관리가 반드시 올바른 방법이라고 생각하지 않습니다.나는 그 일로 좋은 성공을 거두었다. Unison 파일 동기화 장치 이는 두 시스템에서 일관된 홈 디렉토리를 유지하려는 목적으로 설계되었습니다.현재 7개의 레플리카를 한마음으로 관리하고 있는데 세부적인 부분은 좀 까다롭지만 훌륭한 도구이고 2개부터 시작한다면 매우 만족스러울 것입니다.

Unison과 VCS의 주요 차이점은 Unison은 병합해야 하는 충돌 처리를 기꺼이 지연시킨다는 것입니다.게다가 모든 기본값이 올바르게 설정됩니다.그리고 그것은 빠릅니다:나는 DSL 회선을 통해 매일 약 40GB의 데이터를 동기화하는 데 사용합니다.

모든 DVCS는 정상적으로 작동할 것입니다.내가 가장 좋아하는 것은 바자.구성 파일을 .config에 보관하고 해당 버전을 지정한 다음 적절하게 심볼릭 링크를 연결하는 것이 가장 쉽습니다.

DVCS의 이점은 전역 구성의 버전 관리를 방해하지 않고 컴퓨터별 구성 파일의 버전도 지정할 수 있다는 것입니다.

버전 제어 소프트웨어는 홈 디렉토리에 적합하지 않습니다.더 나쁜 것은 일부 소프트웨어가 .svn 폴더를 별로 좋아하지 않거나 그 내용을 해석하기 시작한다는 것입니다.물론 매우 복잡한 미러링 설정을 사용하여 이 문제를 해결하려고 시도할 수도 있지만 이는 어렵습니다.

다음은 이를 시도한 Mozilla 개발자입니다: 내 홈 디렉토리를 관리하는 버전, 댓글에 몇 가지 제안사항이 있습니다.

자식 또는 머큐리얼의 저렴한 분기는 이 상황에 아주 효과적일 것입니다.저는 Mercurial이 더 간단하기 때문에 시작했지만 나중에 git으로 옮겼습니다.

이를 매우 유연하게 처리하는 한 가지 방법은 실제 홈 디렉터리(자체 문제가 있음)를 시도하고 svn하지 않고 개정 제어하에 빌드 디렉터리를 두는 것입니다.

그래서 이 안에는 다음과 같은 구조를 유지합니다

/home/you/code/dotfiles
/home/you/code/dotfiles/dotbashrc
/home/you/code/dotfiles/dotemacs
...
/home/you/code/dotfiles/makefile

makefile에는 파일을 특수화하기 위한 논리가 포함될 수 있습니다(또는 포함하지 않을 수도 있음).

필요한 것보다 무거울 수도 있지만 실제 설정이 복잡하다면(한 번에 3~4개의 서로 다른 유니스에서 이 작업을 수행했습니다) 이와 같은 작업을 수행할 가치가 있습니다.

나는 이것을 위해 git을 사용합니다.지금까지 분기나 병합이 필요 없이 여러 시스템의 홈 디렉토리를 동기화된 상태로 유지할 수 있었습니다.대신에 나는 git rebase.지금까지 갈등은 거의 없었고 해결하기도 쉬웠습니다.

별도의 내용이 필요한 파일은 개정 관리에서 제외하여 보관합니다. .gitignore.

저는 git에 다음 도구에 대한 구성 파일을 보관합니다.

  • 다양한 껍질
  • emacs 및 애플리케이션, 즉
    • 그누스
    • BBDB
    • 이맥스-w3m
  • 바보
  • 화면
  • 다양한 유틸리티 및 스크립트

나는 자체 git 저장소가 있는 하위 디렉토리에 메모 등을 보관합니다.

나는 조사해 볼 것을 제안한다. etckeeper 아직 하지 않았다면.버전 제어 시스템을 사용하여 /etc의 구성 파일 버전을 관리하도록 설계되었습니다.

ETCKEEPER는 GIT, Mercurial, DARCS 또는 BZR 저장소에 저장할 수 있도록 도구 모음입니다.패키지 업그레이드 중에 /etc에 대한 변경 사항을 자동으로 저지르기 위해 APT (및 Yum 및 Pacman-G2를 포함한 다른 패키지 관리자)에 연결됩니다.Revison Control Systems가 일반적으로 지원하지는 않지만 /etc /shadow의 권한과 같은 /etc에 중요하다는 파일 메타 데이터를 추적합니다.개정 제어 작업의 기본 사항을 이해하면 모듈화되고 구성 가능하지만 사용하기가 간단합니다.

/etc용으로 설계되었지만 기본적인 요구 사항은 동일하므로 홈 디렉토리에도 (어쩌면 약간의 적응을 가하면) 잘 작동할 것이라고 생각합니다.

나는 이것이 오래된 스레드라는 것을 알고 있지만 일부 도트 파일을 검색하는 동안 발견했습니다.

현재 시스템은 Subversion을 사용하고 있습니다.내가 한 핵심 작업은 ~/.svnhome/에서 작업 복사본을 체크아웃하는 것이었습니다(돌이켜보면 .dotfiles 또는 좀 더 일반적인 이름으로 불렀어야 했습니다).그런 다음 해당 컴퓨터에서 실제로 사용하는 파일에 대한 심볼릭 링크를 집으로 만듭니다.예를 들어 내 .procmail 및 .spamassassin 폴더는 메일 서버에만 필요하므로 홈 서버에 연결하지 않습니다.

몇 가지 차이점이 있는 유일한 파일은 .bashrc 파일에 macport용으로 내 Mac에 몇 가지 추가 줄이 있다는 것입니다.따라서 .bashrc 하단에서 .bashrc_local이 존재하는지 확인하고 이를 구문 분석합니다.

이것이 Subversion을 사용하는 마지막 남은 것입니다(다른 모든 것은 작업 외에 git을 사용합니다).svn의 장점은 왜냐하면 이는 dvc가 아니므로 실수로 한 서버에 커밋하고 푸시하는 것을 잊어버릴까 봐 걱정할 필요가 없습니다.

브랜치를 만들 수 있도록 git으로 옮기는 것을 고려했습니다.위의 예를 사용하면 주 서버에 .procmail 및 .spamassassin 폴더를 추가하지만 master 분기에는 없는 분기가 있게 됩니다.그러나 현재 시스템은 Git이 존재하기도 전에 수년 동안 잘 작동했으며 지금은 이를 변경할 특별한 동기가 없습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top