대규모 조직에서 Mercurial 사용

대규모 조직에서 Mercurial 사용

---

나는 한동안 내 개인 프로젝트에 Mercurial을 사용해 왔으며 그것을 좋아합니다. 내 고용주는 CVS에서 SVN으로의 전환을 고려하고 있지만 대신 Mercurial (또는 다른 DVCS)을 추진해야하는지 궁금합니다.

Mercurial의 한 가지 주름은 "프로젝트"당 단일 저장소를 갖는 아이디어를 중심으로 설계된 것처럼 보인다는 것입니다. 이 조직에는 계층 적으로 구성된 현재 CVS 저장소에 수십 개의 다른 실행 파일, DLL 및 기타 구성 요소가 있습니다. 재사용 가능한 일반 구성 요소가 많이 있지만 일부 고객 별 구성 요소 및 고객 별 구성도 있습니다. 현재 빌드 절차는 일반적으로 CVS 저장소에서 일부 하위 트리 집합을 가져옵니다.

CVS에서 Mercurial로 이동하는 경우 저장소 / 저장소를 구성하는 가장 좋은 방법은 무엇입니까? 모든 것을 포함하는 하나의 거대한 Mercurial 저장소가 있어야합니까? 그렇지 않다면 작은 저장소는 얼마나 세분화되어야합니까? 나는 사람들이 여러 곳에서 업데이트를 가져오고 푸시해야하는 경우 매우 짜증나게 할 것이라고 생각하지만 회사 코드베이스 전체를 가져 오거나 밀어야하는 경우에도 짜증이 날 것입니다.

누구든지 이것에 대한 경험이나 조언이 있습니까?

---

관련 질문 :

• 엔터프라이즈의 Git 기반 소스 제어 : 권장 도구 및 사례?
• 거대한 프로젝트를위한 분산 버전 제어-가능합니까?

---

AFAICS의 DVCS에 대한 저항의 대부분은 사용 방법을 이해하지 못하는 사람들에게서 비롯됩니다. "중앙 저장소가 없다"라는 자주 반복되는 진술은 태초부터 CVS / SVN 모델에 갇혀 있고 다른 것을 상상할 수없는 사람들에게 매우 무섭습니다. 특히 경영진과 고위직 (경험이 있거나 냉소적) 강력한 소스 코드 추적 및 재현성을 원하는 개발자 (한때 제가 일했던 곳에서했던 것처럼 개발 프로세스와 관련된 특정 표준을 충족해야하는 경우에도 마찬가지). 글쎄, 당신은 중앙의 "축복 된"저장소를 가질 수 있습니다 당신은 그것에 묶여 있지 않습니다. 예를 들어, 서브 팀이 한동안 워크 스테이션 중 하나에 내부 놀이터 저장소를 설정하는 것은 쉽습니다.

속담의 고양이를 피부로 가꾸는 방법은 너무나 많기 때문에 앉아서 작업 흐름에 대해 신중하게 생각하는 것이 좋습니다. 현재 관행과 거의 무료 복제 및 분기가 제공하는 힘에 대해 생각해보십시오. 현재 수행중인 작업 중 일부는 CVS 유형 모델의 한계를 해결하기 위해 발전했을 것입니다. 곰팡이를 깰 준비를하십시오. 전환 과정에서 모든 사람을 편하게하려면 챔피언 한두 명을 지정해야 할 것입니다. 큰 팀에서는 blessed 에 대한 커밋 액세스 제한에 대해 생각하고 싶을 것 입니다.

내 직장 (작은 소프트웨어 하우스)에서 우리는 CVS에서 hg로 옮겼고 돌아 가지 않았습니다. 우리는 대부분 중앙 집중식으로 사용하고 있습니다. 메인 (고대 및 매우 큰) 리포지토리를 변환하는 것은 고통 스러웠지만 어떤 방식 으로든 진행할 수 있으며 완료되면 나중에 VCS를 변경하는 것이 훨씬 쉬울 것입니다. (우리는 CVS 변환 도구가 무슨 일이 일어 났는지 알아낼 수없는 여러 상황을 발견했습니다. 누군가의 커밋이 부분적으로 만 성공했고 며칠 동안 눈치 채지 못한 경우, 공급 업체 지점 해결, 시간에 따른 광기와 광기 거꾸로, 다른 시간대의 현지 시간 커밋 타임 스탬프의 도움이되지 않습니다 ...)

DVCS의 가장 큰 장점은 초기에 커밋하고 자주 커밋하고 준비가되었을 때만 푸시 할 수 있다는 것입니다. 진행중인 다양한 이정표에 도달하면 모래 위에 줄을 지어 필요에 따라 되돌릴 수있는 곳을 마련하는 것을 좋아합니다.하지만 이는 명백히 불완전하기 때문에 팀에 노출되어야하는 커밋이 아닙니다. 무수히 많은 방법으로. (저는 주로 수은 대기열로이 작업을 수행합니다.) 워크 플로에 관한 모든 것입니다. 나는 CVS로 이것을 결코 할 수 없었습니다.

이미 알고 계시 겠지만, CVS에서 벗어나고 자한다면 SVN보다 훨씬 더 잘할 수 있습니다.

---

모놀리스로, 아니면 모듈로? 어떤 패러다임 전환은 VCS를 사용하든 배포하든 상관없이 까다로울 것입니다. CVS 모델은 나머지 저장소가 최신 상태인지 확인하지 않고 파일 단위로 커밋 할 수 있다는 점에서 매우 특별합니다 (모듈 별칭으로 인해 발생하는 골칫거리는 언급하지 않겠습니다).

• 모 놀리 식 저장소를 다루는 것은 꽤 느릴 수 있습니다. vcs 클라이언트는 단일 모듈이 아닌 전체 유니버스의 복사본을 스캔하여 변경 사항을 확인해야합니다. (Linux에서 작업하는 경우 아직 수행하지 않은 경우 hg inotify 확장을 살펴보십시오.)
• 모 놀리 식 저장소는 커밋 (푸시) 할 때 불필요한 경쟁 조건을 유발하기도합니다. CVS 최신 확인과 비슷하지만 전체 저장소에 적용됩니다. 활성 개발자가 많고 자주 커밋하면이 항목이 당신을 물릴 것입니다.

모 놀리 식에서 벗어나려는 노력의 가치가 있다고 제안하지만 빌드 시스템에 추가 된 복잡성 측면에서 자체 오버 헤드를 부과 할 것입니다. (참고 : 귀찮은 일을 발견하면 자동화하십시오! 우리 프로그래머는 결국 게으른 생물입니다.) 저장소를 모든 구성 요소 모듈로 분할하는 것은 너무 극단적 일 수 있습니다. 적은 수의 리포지토리 사이에 그룹화 된 관련 구성 요소가있는 중간 하우스가있을 수 있습니다. mercurial의 하위 모듈 지원 인 Nested Repositories 와 Forest Extension 을 살펴 보는 것도 유용 할 것입니다 (둘 다 내 머리를 둘러보아야합니다).

이전 직장에서 우리는 상당히 체계적인 메타 구조를 가진 독립적 인 CVS 모듈로 유지되는 수십 개의 구성 요소를 가지고있었습니다. 구성 요소는 자신이 의존하는 것과 어떤 부품을 어디에 내보낼 것인지 선언했습니다. 빌드 시스템은 작업중인 작업이 필요한 것을 선택할 수 있도록 자동으로 make 조각을 작성했습니다. 일반적으로 매우 잘 작동했으며 CVS 최신 검사에 실패하는 경우는 매우 드뭅니다. (또한 의존성 해결에 대해 최소한의 노력을 기울이는 매우 복잡하지만 매우 강력한 빌드 봇이있었습니다. 이미 요구 사항을 충족하는 구성 요소가 있으면 구성 요소를 다시 빌드하지 않을 것입니다. 설치 프로그램과 전체를 조립하는 메타 구성 요소에 추가하십시오. ISO 이미지를 사용하면 쉽게 시작부터 완료까지 빌드하고 Sorcerers Apprentice를 진행할 수있는 좋은 레시피가 있습니다.

---

공개 : 이것은 git에 초점을 맞춘 다른 스레드 의 교차 게시물 이지만 어쨌든 mercurial을 추천하게되었습니다. 일반적으로 엔터프라이즈 컨텍스트에서 DVCS를 다루기 때문에 교차 게시가 괜찮기를 바랍니다. 이 질문에 더 잘 맞도록 약간 수정했습니다.

---

일반적인 의견과 달리 DVCS는 매우 유연한 워크 플로우를 가능하게하므로 기업 환경에서 이상적인 선택이라고 생각합니다. 먼저 DVCS 대 CVCS 사용, 모범 사례, 특히 git에 대해 이야기하겠습니다.

엔터프라이즈 컨텍스트에서 DVCS 대 CVCS :

여기서는 일반적인 장단점에 대해 이야기하지 않고 상황에 초점을 맞 춥니 다. DVCS를 사용하려면 중앙 집중식 시스템을 사용하는 것보다 더 잘 훈련 된 팀이 필요하다는 것이 일반적인 개념입니다. 이는 중앙 집중식 시스템이 워크 플로우 를 쉽게 시행 할 수있는 방법을 제공하기 때문입니다. 분산 형 시스템을 사용하려면 설정된 규칙을 고수 하려면 더 많은 의사 소통 과 규율이 필요합니다 . 이것이 오버 헤드를 유발하는 것처럼 보일 수 있지만, 좋은 프로세스를 만들기 위해 필요한 의사 소통 증가의 이점이 있습니다. 팀은 일반적으로 코드, 변경 사항 및 프로젝트 상태에 대해 통신해야합니다.

규율의 맥락에서 또 다른 차원은 분기와 실험을 장려하는 것입니다. 다음 은 버전 제어 도구에 대한 Martin Fowlers의 최근 bliki 항목의 인용문입니다 . 그는이 현상에 대한 매우 간결한 설명을 발견했습니다.

DVCS는 실험을위한 빠른 분기를 권장합니다. Subversion에서 분기를 수행 할 수 있지만 모든 사람이 볼 수 있다는 사실은 사람들이 실험 작업을 위해 분기를 열지 못하게합니다. 마찬가지로 DVCS는 작업의 체크 포인트를 장려합니다. 컴파일하거나 테스트를 통과하지 못할 수도있는 불완전한 변경 사항을 로컬 저장소에 커밋하는 것입니다. 다시 Subversion의 개발자 분기에서이 작업을 수행 할 수 있지만 이러한 분기가 공유 공간에 있다는 사실은 사람들이 그렇게 할 가능성을 줄입니다.

DVCS는 단순한 텍스트 차이 대신 DAG (Directed Acyclic Graph)에서 전역 적으로 고유 한 식별자를 통해 변경 집합 추적을 제공하므로 유연한 워크 플로를 지원합니다. 이를 통해 매우 중요 할 수있는 변경 집합의 출처와 기록을 투명하게 추적 할 수 있습니다.

워크 플로우 :

Larry Osterman (Windows 팀에서 작업하는 Microsoft 개발자)은 Windows 팀에서 사용하는 워크 플로에 대한 훌륭한 블로그 게시물을 가지고 있습니다. 특히 다음과 같은 이점이 있습니다.

• 깨끗한 고품질 코드 전용 트렁크 (마스터 리포지토리)
• 모든 개발은 기능 브랜치에서 이루어집니다.
• 기능 팀에는 팀 저장소가 있습니다.
• 그들은 정기적으로 최신 트렁크 변경 사항을 기능 브랜치에 병합합니다 ( Forward Integrate ).
• 완전한 기능은 검토, 테스트 범위, Q & A (자체 리포지토리)와 같은 여러 품질 게이트를 통과해야합니다.
• 기능이 완성되고 허용되는 품질이있는 경우 트렁크에 병합됩니다 ( Reverse Integrate )

보시다시피 이러한 각 저장소를 자체적으로 유지하면 서로 다른 속도로 진행하는 서로 다른 팀을 분리 할 수 ​​있습니다. 또한 유연한 품질 게이트 시스템을 구현할 수있는 가능성은 DVCS와 CVCS를 구별합니다. 이 수준에서도 권한 문제를 해결할 수 있습니다. 소수의 사람 만 마스터 리포지토리에 액세스 할 수 있어야합니다. 계층 구조의 각 수준에 대해 해당 액세스 정책이있는 별도의 저장소가 있습니다. 실제로이 접근 방식은 팀 수준에서 매우 유연 할 수 있습니다. 팀 리포지토리를 서로 공유할지 또는 팀 리더 만 팀 리포지토리에 맡길 수있는보다 계층 적 접근 방식을 원하는지 결정하려면 각 팀에 맡겨야합니다.

(The picture is stolen from Joel Spolsky's hginit.com.)

One thing remains to be said at this point, even though DVCS provides great merging capabilities, this is never a replacement for using Continous Integration. Even at that point you have a great deal of flexibility: CI for the trunk repo, CI for team repos, Q&A repos etc.

Mercurial in an enterprise context:

I don't want to start a git vs. hg flamewar here, you are already on the right track by considering switching to DVCS. Here are a couple of reasons to use Mercurial instead of git:

• All plattforms that run python are supported
• Great GUI tools on all major plattforms (win/linux/OS X), first class merge/vdiff tool integration
• Very consistent interface, easy transition for svn users
• Can do most of the things git can do too, but provides a cleaner abstraction. Dangerous operations are are always explicit. Advanced features are provided via extensions that must explicitly be enabled.
• Commercial support is available from selenic.

In short, when using DVCS in an enterprise I think it's important to choose a tool that introduces the least friction. For the transition to be successful it's especially important to consider the varying skill between developers (in regards to VCS).

There are a couple of resources I'd like to point you to in the end. Joel Spolsky has recently written an article defeating a lot of arguments brought up against DVCS. It must be mentioned others have discovered these contra-arguments long before. Another good resource is Eric Sinks blog, where he wrote an article about Obstacles to an enterprise DVCS.

---

First of all, some recent discussion on using a DVCS in huge projects is relevant:

Distributed version control for HUGE projects - is it feasible?

One wrinkle with Mercurial is that it seems to be designed around the idea of having a single repository per "project".

Yes, while the norm with Subversion is to have one monolithic repository containing multiple projects, with a DVCS it is preferable to have more granular repositories, with one per component. Subversion has the svn:externals feature to aggregate multiple source trees at checkout time (which has its own logistical and technical issues). Both Mercurial and Git have a similar feature, called subrepos in hg.

The idea with subrepos is you have one repo per component, and a releasable product (comprising multiple reusable components) will simply refer to its dependent repos. When you clone the product repo, it brings along the components it needs.

Should we have one huge Mercurial repository containing everything? If not, how fine-grained should the smaller repositories be? I think people will find it very annoying if they have to pull and push updates from a lot of different places, but they will also find it annoying if they have to pull/push the entire company codebase.

It is certainly possible to have one monolithic repository (and you can even split it up down the track if you need to). The issues with this approach are more likely to come down to release schedles, and how you manage different versions of different components. If you have multiple products with their own release schedules sharing common components, you would probably be better off with a more granular approach, to facilitate configuration management.

One caveat is that the subrepo support is a relatively recent feature, and is not as fully fledged as other features. Specifically, not all hg commands know about subrepos, although the most important ones do.

I suggest you perform a test conversion, and experiment with the subrepo support, organising products and dependent components, etc. I am in the process of doing the same thing, and this seems to be the way to go.

참고URL : https://stackoverflow.com/questions/2479274/using-mercurial-in-a-large-organization