mercurial 유스 케이스 솔루션

Question

내가 참여하고있는 프로젝트에는 다른 개발자가 관리하는 많은 작은 모듈이 있습니다. 우리는 현재 svn을 사용하고 있지만 수은으로 전환하고 싶습니다. 클라이언트 사이트로 이동해야하고 약간의 개발로 인해 버전 관리가 어려워집니다.

그러나 전체 트렁크는 약 4 ~ 5GB로 거대하며 모든 모듈에 대해 하나의 저장소를 만드는 것은 내가 필요로하는 저장소를 묶어야한다면 이 4-5 기가의 파일을 이동하려면 .. 그리고 나는 더 작은 모듈 (그것들은 .hg 폴더를 가지고 있지 않다)의 백업을 취한다. 그것은 .hg 폴더가 존재하는 하나의 기본 폴더 내에있다. 방법은 백업 된 모듈 (폴더)에서 comitting의 .. 그래서 한 프로젝트가 많은 모듈을 가지고 말을 그런 상황에서 처리하는 가장 좋은 방법은 ... 개발자는 개별 모듈을 가지고 (최소 크기로 데이터 크기를 유지하면서) 원하는 곳에 코드를 작성한 다음 다시 가져와 해당 분기를 병합합니다.

내 마음 속에 떠오르는 하나의 명백한 해결책은 모든 모듈이 레포가되지만 하나의 통합 된 제품이 출시 될 때 특별히 관리하기가 어렵다는 것입니다. 어떤 버전이 출시 될 예정입니까? 모든 모듈이 거기에 자신의 버전 기록을 가지고있을 것이기 때문에 ??

더 완벽한 경우는 svn 히스토리를 수은으로 변환하면됩니다. 트렁크에서 변환을 수행하면 단일 repo가되지만 거대한 크기로 생성됩니다. 모든 모듈 소유자는이 거대한 번들을 사용합니다 그와 함께 매번 의미가 없을 것입니다 ...

그래서 어떤 제안 ??

감사합니다.

Answer 1

Tonfa는 코멘트에서 말합니다.하지만 대답으로 거기에 넣을 것입니다 : Mercurial의 Submodule Support을 사용하십시오. 그것은 expirimental라고 말하지만, 주요 버그 또는 변경 사항없이 1.3 버전의 몇 달 동안이나 변경되었으므로 향후 변경 사항이 역 호환 될 영역에 있다고 생각됩니다.

또한 대용량 파일 (10MB 이상)이있는 경우 rep을 사용하여 직접 컨트롤 밖으로 이동할 수 있지만 버전은 계속 추적 할 수 있습니다.

일반적으로 빌드 스크립트를 소스 코드에 넣는 대신 크고 손으로 편집하지 않는 자산을 다운로드 할 수 있도록 충분히 포괄적으로 만들면 repos는 4 또는 5로 성장하지 않는 경향이 있습니다 GB - KLoC가 많이 있습니다. 어쩌면이 마이그레이션은 Ivy 같은 종속성 다운로드 도구를 사용하거나 개발 환경에 적합한 도구를 사용하기에 좋은시기입니다.

Answer 2

웹 사이트에서 우리는 MP3 및 FLV 파일을 제외하고 모든 파일을 수은 아래에 넣습니다. 우리는 거의 300MB 이상을 얻지 못합니다. 게다가, 디스크는 싸다. 사용자와 고객 사이트 (또는 보안 문제) 사이에 대역폭 문제가있는 경우 전체 트리를 엄지 드라이브에 복제하고 고객 사이트로 가서 해킹 한 다음 집으로 오면 병합이 변경됩니다.

Mercurial은 근본적으로 버전 제어 방식을 변경했습니다. 이것과 같은 것들은 큰일이었고 지금은 ... 어.