HUGE 프로젝트를위한 분산 버전 제어 - 실현 가능합니까?

Question

우리는 지금 SVN에 상당히 만족하지만 Joel's tutorial은 나를 흥미롭게 만들었습니다. 그래서 나는 궁금해했다 - 우리 상황에서도 실현 가능할 것인가?

것은 - 우리 SVN 저장소가 거대합니다. 소프트웨어 자체는 15 년의 전통을 가지고 있으며 이미 여러 가지 소스 제어 시스템에서 살아 남았습니다. 68,000 개가 넘는 리비전 (변경 세트)이 있으며 소스 자체가 100MB 이상을 차지하고 전체 저장소가 얼마나 많은 GB를 소비하는지 짐작할 수 있습니다.

그런 다음 문제는 간단합니다. 전체 저장소의 복제본을 만드는 데 시간이 오래 걸릴 것이므로 멀리 떨어져있는 드라이브에서 훨씬 더 많은 공간을 사용하게됩니다. 그리고 분산 버전 관리의 요점은 필요한만큼 많은 저장소가 있어야하기 때문에 의심스러워지기 시작했습니다.

Mercurial (또는 다른 분산 버전 제어)은 어떻게 처리합니까? 아니면 거대한 프로젝트에서 사용할 수 없습니까?

추가 : 명확히하기 위해 - 모든 것은 하나의 .EXE로 컴파일되는 프로젝트의 하나의 모 놀리 식 짐승이며 분리 될 수 없습니다.

2 : 두 번째 생각 - Linux 커널 저장소는 git를 사용하며 아마도 내 것보다 두 배 큰 것입니다. 그럼 어떻게하면 효과가 있습니까?

Answer 1

100MB의 소스 코드가 Linux 커널보다 작습니다. Linux 커널 2.6.33과 2.6.34-rc1 사이의 변경 사항은 6604 커밋을가집니다. 저장소 규모가 저를 협박하는 것처럼 들리지는 않습니다.

리눅스 커널 2.6 헤드가 주요 리누스의 트리에서 체크 아웃 445메가바이트 :

• 리눅스 커널 .tar.bz2 아카이브에서 압축 2.6.34-RC1

두 번 827메가바이트 많은,하지만 여전히 땅콩 우리 모두가 가지고있는 거대한 하드 드라이브로

Answer 2

당신은 하나의 거대한 저장소를 오래된 저장소에있는 각 모듈에 대한 많은 작은 저장소로 나눕니다. 그렇게하면 사람들은 이전에 가지고 있었을 SVN 프로젝트가 무엇이든 관계없이 저장소로 보관할 수 있습니다. 이전보다 훨씬 많은 공간이 필요합니다.

Answer 3

아니요, 작동하지 않습니다. 당신은 고객 측에서 사물 보관을 요구하는 것을 원하지 않습니다. 이 크기가 커지면 (예 : 이미지 재배포), 스토리지는 일반 워크 스테이션보다 더 효율적이어야합니다.

그러면 중앙 집중식으로 작업하는 것이 좋습니다. 간단한 수학 - simlpy는 모든 워크 스테이션에서 gb를 사용하는 것이 불가능하고 효율적입니다. 단순히 의미가 없습니다.

Answer 4

모든 기록이 필요합니까? 지난 1 년 또는 2 년 만 필요한 경우, 현재 저장소를 히스토리 참조 용 읽기 전용 상태로 두는 것을 고려할 수 있습니다. 그런 다음 새로운 히스토리를 가진 새로운 저장소를 작성하십시오. 하위 리비전이있는 svnadmin dump을 수행하면 새 분산 저장소의 기반이됩니다.

나는 100MB 작업 카피와 68K 개정이 그다지 크지 않다는 다른 대답에 동의한다. 한번 해봐.

Answer 5

상당히 큰 C#/.net 프로젝트 (1 개 솔루션에서 68 개 프로젝트)에서 git을 사용하고 전체 트리를 새로 가져온 TFS 풋 프린트는 ~ 500Mb입니다.상당한 양의 커밋을 저장하는 git repo는 로컬에서 약 800Mb의 무게가 나간다. 컴팩 션 (Compaction)과 저장소가 내부적으로 git에서 작동하는 방식은 뛰어납니다. 너무 많은 변화가 이처럼 적은 양의 공간을 차지하는 것을 보는 것은 놀랍습니다.

Answer 6

당신은 SVN에 만족한다고 말합니다. 그렇다면 왜 변화합니까?

분산 버전 제어 시스템에 관한 한 Linux는 git을 사용하고 Sun은 Mercurial을 사용합니다. 둘 다 인상적으로 큰 소스 코드 저장소이며 잘 작동합니다. 예, 모든 워크 스테이션에 대한 모든 수정이 완료되었지만 이는 분권화에 대해 지불하는 비용입니다. 스토리지는 저렴합니다. 현재 개발 노트북에는 1TB (2x500GB)의 하드 디스크 스토리지가 장착되어 있습니다. Git 또는 Mercurial 같은 SVN repo를 실제로 시험해 본 적이 있습니까? 걸릴 공간은 어느 정도입니까?

제 질문은 분산 된 조직으로 준비 되었습니까? 소프트웨어 상점의 경우 대개 중앙 저장소 (정기적 인 백업, CruiseControl 또는 FishEye에 대한 연결, 제어 및 관리 용이)를 유지하는 것이 훨씬 더 합리적입니다.

그리고 SVN보다 더 빠르고 확장 성이 뛰어난 제품을 원하면 상용 제품을 구입하십시오. 저는 Perforce와 Rational ClearCase를 모두 사용했으며 아무 문제없이 거대한 프로젝트로 확장 할 수 있습니다.

Answer 7

거대한 프로젝트를위한 분산 버전 제어 - 가능합니까?

물론입니다! 알다시피, Linux는 방대하고 힘내기를 사용합니다. Python, Mozilla, OpenSolaris 및 Java와 같은 Mercurial is used for some major projects도 있습니다.

지금 우리는 SVN에 상당히 만족하지만 조엘의 튜토리얼은 나를 흥미롭게 만들었다. 그래서 나는 궁금해했다 - 우리 상황에서도 실현 가능할 것인가?

예. Subversion에 만족한다면 많은 분기와 병합을하지 않을 것입니다!

우리의 SVN 저장소는 거대합니다. [...] 68,000 개가 넘는 리비전 (변경 집합)이 있습니다. 소스 자체가 100MB 이상을 차지합니다.

다른 사람들이 지적했듯이 실제로 많은 기존 프로젝트와 비교할 때 그다지 크지는 않습니다.

문제는 간단합니다. 전체 저장소의 복제본에 시간이 오래 걸리고 원격으로는 훨씬 더 많은 공간이 소모됩니다.

Git와 Mercurial 모두 저장소 관리에 매우 효율적이며 해당 리포지토리가 동일한 Subversion repo (몇 개 변환)보다 훨씬 적은 공간을 차지합니다. 그리고 처음 체크 아웃을하면 델타를 누를 뿐이며 은 매우입니다. 대부분의 작업에서이 둘은 훨씬 빠릅니다. 초기 복제본은 일회성 비용이므로 소요 시간은 중요하지 않습니다. 놀랍습니다.

그리고 분산 버전 관리의 요점은 필요한만큼의 저장소가 있어야하므로 의심이갑니다.

디스크 공간이 쌉니다. 개발자 생산성은 훨씬 더 중요합니다. 그래서 repo가 ​​1GB를 차지한다면? 더 똑똑하게 일할 수 있다면, 그만한 가치가 있습니다.

Mercurial (또는 다른 분산 버전 제어)은 어떻게 처리합니까? 아니면 거대한 프로젝트에서 사용할 수 없습니까?

모질라가 변환 프로세스를 어떻게 관리했는지와 같은 projects using Mercurial을 읽는 것이 좋습니다. 대부분이 각각 주요 구성 요소를 포함하는 여러 개의 repos를 가지고 있습니다. Mercurial과 Git은 둘 다 중첩 된 저장소를 지원합니다. 그리고 변환 과정을 관리 할 도구가 있습니다 - Mercurial has built-in support for importing from most other systems.

추가 사항 : 전체 내용은 단일 .EXE로 컴파일되고 분할 할 수없는 프로젝트의 하나의 모 놀리 식 비스트입니다.

그러면 은 하나의 저장소 만 필요하므로은 더 쉽게 만듭니다.

2 추가 : 두 번째 생각 - Linux 커널 저장소는 git를 사용하며 아마 내 것보다 두 배 큰 것입니다. 그럼 어떻게하면 효과가 있습니까?

Git은 원시 속도로 설계되었습니다. 온 - 디스크 포맷, 와이어 프로토콜, 인 - 메모리 알고리즘은 모두 최적화되어 있습니다. 또한 개발자는 개별 개발자, 하위 시스템 관리자, 중위자, 결국 리누스에 이르는 정교한 워크 플로우를 개발했습니다. DVCS에 대한 가장 좋은 점 중 하나는 유연성이 뛰어나므로 모든 종류의 워크 플로가 가능하다는 것입니다.

브라이언 오 설리반 (Bryan O'Sullivan)이 excellent book on Mercurial을 읽는 것이 좋습니다. 그러면 속도가 빨라집니다. Mercurial을 다운로드하고 예제를 통해 작업하고 일부 스크래치 레포지 (scratch repo)에서이 예제를 사용하여 느낀다.

그런 다음 convert 명령을 실행하여 기존 소스 리포지토리를 가져 오십시오. 그런 다음 로컬 변경, 커밋, 분기, 로그보기, 내장 웹 서버 사용 등을 시도하십시오. 그런 다음 다른 상자로 복제하고 변경 사항을 적용하십시오. 시간이 가장 일반적인 작업 및 비교 방법을 참조하십시오. 비용은 들지 않지만 시간을 들여 완벽한 평가를 할 수 있습니다.

Answer 8

내 경험에 비추어 볼 때 Mercurial은 수많은 파일과 거대한 역사를 처리하는 데 능숙합니다. 단점은 10MB보다 큰 파일을 체크인하지 않아야한다는 것입니다. Mercurial을 사용하여 컴파일 된 DLL의 기록을 유지했습니다. 소스 카운트 롤에 바이너리를 두는 것은 권장하지 않지만 어쨌든 (바이너리 전용 저장소) 시도했습니다. 저장소는 약 2 기가이고 우리는 앞으로도 그렇게 할 수 있을지 확신하지 못합니다. 어쨌든 소스 코드에 대해서는 걱정할 필요가 없다고 생각합니다.

Answer 9

힘내는 분명히 당신만큼 큰 프로젝트에서 작동 할 수 있습니다. 지적하면, 리눅스 커널 만이 더 큽니다.

Mercurial과 Git을 사용하여 큰 파일을 관리 할 수 ​​있는지 여부는 알 수 없습니다. 큰 파일 (지금까지)을 관리 할 수 ​​없다는 것입니다.

저는 CVS/SVN (실제 둘을 혼합 한 것)에서 분산 및 중앙 집중식 (동일한 조직 내부에서 일어나는 두 개의 워크 플로우)의 플라스틱 SCM으로 크기를 (그리고 약 15 년 동안) 프로젝트를 이동 한 경험이 있습니다. 같은 시간) 개발.

기술적 인 문제는 아니지만 많은 사람들이 참여하기 때문에 이동이 원활 해지지는 않을 것입니다. (아마도 수백 명의 개발자가 참여하는 프로젝트일까요?)하지만 자동화 할 수있는 수입업자가 있습니다. 마이그레이션 및 교육 또한 매우 빠르게 수행 될 수 있습니다.

Answer 10

저장소 공간 요구 사항에 대해 걱정할 필요가 없습니다. 저의 일화 : SVN에서 코드베이스를 git (전 역사 - 나는 생각합니다)로 변환하면 클론이 WVN 작업 디렉토리보다 공간을 적게 차지한다는 것을 발견했습니다. SVN은 모든 체크 아웃 된 파일의 초기 복사본을 유지합니다. SVN 체크 아웃에서 $ PWD/.svn/text-base /를보십시오. 자식으로 전체 기록 공간이 적습니다.

나를 놀라게 한 것은 네트워크 효율성이 얼마나 가치있는 것인가입니다. 잘 연결된 장소에서 프로젝트의 git 복제본을 만든 다음 플래시 디스크로 집으로 가져갔습니다. 여기에 플래시 디스크로 찍었습니다. 여기에 작은 GPRS 연결로 git fetch/git pull으로 최신 정보를 보관합니다. 나는 SVN 제어 프로젝트에서 같은 것을 할 감히하지 않을 것이다.

정말 시도해 보시려면 직접 자신에게 빚이 있습니다. VCS 중심의 가정이 얼마나 잘못되었는지 당신이 놀랄 것입니다.