Mercurial : 세분화 된 리포지토리 대 버전 리포지토리 및 버전 관리의 타사 도구 공유

Question

시나리오 : 다양한 제품이 더 작은 프로젝트의 조합을 구성했습니다. dev, release 및 maintenace (버그/패치/부 릴리스)의 각 제품에 대한 몇 가지 다른 버전.

대부분의 팀은 dev 및 릴리스 용으로 다양한 타사 도구 및 라이브러리를 사용합니다 (일반적으로 두 개는 dev 용 XUnit이고 제품에는 AutoMapper입니다). 그들은이 도구/라이브러리를 제어하는 ​​버전의 팬입니다.

수은에서 구조를 구성하는 가장 좋은 방법을 이해하지 못하는 것 같습니다. 중앙 SVN 스타일에서는 타사 도구를 자체 프로젝트로 사용하고 다른 프로젝트의 결과물을 가져 오는 프로젝트를위한 작은 빌드를 만든 다음, 건설 프로젝트 모두는 계층 구조로 될

등 (DEV 분기)

Root/dev/ProjectX/ 
Root/dev/ProjectY/ 
Root/dev/ThirdParty/XXX -- could be a 3rd party lib 
Root/dev/ThirdParty/YYY -- could be a 3rd party lib 

(지점 1)

Root/release1/ProjectX/ 
Root/release1/ProjectY/ 
Root/release1/ThirdParty/XXX 
Root/release1/ThirdParty/YYY 

(분기 2)

Root/release2/ProjectX/ 
Root/release3/ProjectY/ 
Root/release2/ThirdParty/XXX 
Root/release2/ThirdParty/YYY 

개발자가하는 방식 때문에 문지름이 온다. (NUGET 패키지 관리자를 사용하여) 자신의 컴퓨터를 최신 상태로 유지하려면 개발자가 각 프로젝트마다이 라이브러리를 여러 개 가질 필요가 없도록 타사 항목이 모두 ThirdParty 폴더에 있어야합니다. 그들은 수은 여기에 simmilar 전략 (대규모 저장소) 및 복제/분기를 구현해야합니다 구현하거나 프로젝트 레벨 이러한 복제/지점에서 말하는 저장소를 깨지면

:

내 질문은 이것이다. 후자의 경우에는 제품/버전 지사/저장소가 있습니까? 나는 새로운 워크 플로우 학습의 어려움이 처음에는 어렵더라도, 장기간에 더 잘 작동한다면 분산 모델을 선호 할 것이라는 것을 안다.

나는 http://nvie.com/posts/a-successful-git-branching-model/과 많은 기사를 읽었지 만, 나는 여전히 어떻게 조직해야하는지 확신 할 수 없다.

Answer 1

기본적으로 각 제품, 각 프로젝트 및 타사 라이브러리에 대해 별도의 repo를 만든 다음 subrepositories에 적절하게 조합합니다. 중앙 서버 (또는 서버)에, 나는 아마 이런 식으로 베어의 repos의 구조를 설정합니다 :

products/ProductA/ 
      ProductB/ 
      ProductC/ 
    projects/ProjectA/ 
      ProjectB/ 
      ProjectC/ 
thirdparty/ThirdPartyA/ 
      ThirdPartyB/ 
      ThirdPartyC/ 

당신이 당신의 중앙 서버에 각각의 repo의 정확히 하나의 복사본을 가지고 이쪽으로. mercurial은 하나의 저장소에 여러 분기를 저장할 수 있기 때문에 각 분기마다 별도의 저장소를 만들 필요가 없습니다.

그런 다음 누군가가 로컬 저장소에서 제품을 체크 아웃하면 해당 프로젝트 및 제 3 자 라이브러리의 작업 트리를 체크 아웃하는 데 서브repo 메커니즘을 사용합니다. 로컬 디스크에서 구조는 다음과 같이 표시됩니다 이것은 중앙 서버에 다른 보이는

ProductA/ 
     ProjectA/ 
     ProjectB/ 
     ThirdParty/ 
        ThirdPartyC/ 

이 당신의 subrepos에 유일한 포인터 작업 나무가 없기 때문에.