[version-control] 중앙 집중식 및 분산 형 버전 제어 시스템 비교 [닫기]

W. Craig Trader 는 DVCS 및 CVCS에 대해 다음과 같이 말했습니다.

둘 다 필요하면 fsck’d입니다.

나는 둘 다 사용할 때 당신이 fsck’d 라고 말하지 않을 것 입니다. 실제로 DVCS 도구를 사용하는 개발자는 일반적으로 변경 사항을 중앙 위치 (일반적으로 릴리스 저장소의 릴리스 브랜치)에 병합 (또는 풀 요청 전송)하려고합니다. DVCS를 사용하는 개발자에게는 아이러니가 있지만 결국 중앙 집중식 워크 플로를 고수하면 분산 접근 방식이 중앙 집중식보다 더 나은지 궁금해 할 수 있습니다.

DVCS는 CVCS에 비해 몇 가지 장점이 있습니다.

• 고유하게 인식 할 수있는 커밋이라는 개념으로 인해 피어간에 패치를 쉽게 보낼 수 있습니다. 즉, 패치를 커밋으로 만들고이를 필요로하는 다른 개발자와 공유합니다. 나중에 모든 사람이 함께 병합하려고 할 때 해당 특정 커밋이 인식되고 분기간에 비교할 수 있으므로 병합 충돌 가능성이 줄어 듭니다. 개발자는 사용하는 버전 관리 도구에 관계없이 USB 스틱이나 이메일을 통해 서로에게 패치를 보내는 경향이 있습니다. 불행히도 CVCS의 경우 버전 제어는 커밋을 개별적으로 등록하여 변경 사항이 동일하다는 것을 인식하지 못하여 병합 충돌 가능성이 높아집니다.

• 다른 사람에게 보여줄 필요가없는 로컬 실험 분기 (복제 된 저장소도 분기로 간주 될 수 있음)를 가질 수 있습니다. 즉, 업스트림으로 푸시하지 않은 경우 주요 변경 사항이 개발자에게 영향을 미칠 필요가 없습니다. CVCS에서 여전히 브레이킹 체인지가있는 경우이를 수정하고 그때까지 변경 사항을 커밋 할 때까지 오프라인으로 작업해야 할 수 있습니다. 이 접근 방식은 버전 관리를 안전망으로 사용하는 목적을 효과적으로 무효화하지만 CVCS에서는 필수 악입니다.

• 오늘날의 세계에서 회사는 일반적으로 해외 개발자와 협력합니다 (또는 더 나은 경우에는 재택 근무를 원합니다). DVCS를 사용하면 모든 사람이 자신의 저장소를 가지고 있기 때문에 안정적인 네트워크 연결이 필요하지 않기 때문에 이러한 종류의 프로젝트에 도움이됩니다.

… 일반적으로 해결 방법이있는 몇 가지 단점 :

• 누가 최신 버전을 가지고 있습니까? CVCS에서 트렁크에는 일반적으로 최신 개정판이 있지만 DVCS에서는 명확하지 않을 수 있습니다. 해결 방법은 프로젝트의 개발자가 작업을 병합 할 repo에 대해 합의해야하는 행동 규칙을 사용하는 것입니다.

• 비관적 잠금, 즉 체크 아웃 할 때 파일이 잠기는 것은 일반적으로 DVCS의 저장소간에 발생할 수있는 동시성으로 인해 불가능합니다. 버전 제어에 파일 잠금이 존재하는 이유는 개발자가 병합 충돌을 피하기를 원하기 때문입니다. 그러나 잠금은 두 명의 개발자가 긴 트랜잭션 모델과 같이 동일한 코드를 동시에 작업 할 수없고 병합 충돌에 대한 완전한 보증이 아니기 때문에 개발 속도를 늦추는 단점이 있습니다. 버전 제어에 관계없이 정상적인 방법은 큰 병합 충돌을 방지하는 것입니다 (낮은 커플 링 높은 응집력과 같은) 좋은 코드 아키텍처를 가지고 작업 작업을 분할하여 코드에 미치는 영향을 최소화하는 것입니다. .

• 독점 프로젝트에서 전체 저장소가 공개적으로 사용 가능 해지면 재앙이 될 것입니다. 불만을 품거나 악의적 인 프로그래머가 복제 된 저장소를 손에 넣는 경우 더욱 그렇습니다. 소스 코드 유출은 독점 기업에게 심각한 고통입니다. DVCS는 저장소를 복제하기 만하면되는 반면 일부 CM 시스템 (예 : ClearCase)은 해당 액세스를 제한하려고하므로이를 단순하게 만듭니다. 그러나 제 생각에는 회사 문화에 충분한 역기능이 있다면 전 세계의 버전 관리가 소스 코드 유출을 방지하는 데 도움이되지 않습니다.