중앙 집중식 버전 제어 시스템 (DVCS) 을 사용할 때의 장점과 단점 은 무엇입니까 ? DVCS에서 문제가 발생했으며 이러한 문제에 대해 어떻게 보호 했습니까? 토론 도구는 불가지론적이고 불타 오르는 것을 최소화하십시오.
어떤 DVCS 도구를 사용할 수 있는지 궁금한 사람들을 위해 가장 잘 알려진 무료 / 오픈 소스 DVCS 목록은 다음과 같습니다.
답변:
분산 버전 제어 시스템 (DVCS)은 중앙 집중식 VCS와는 다른 문제를 해결합니다. 그것들을 비교하는 것은 망치와 드라이버를 비교하는 것과 같습니다.
중앙 집중식 VCS 시스템은 축복받은 하나의 진정한 소스가 있으므로 좋은 의도로 설계되었습니다. 모든 개발자는 해당 소스에서 작업 (체크 아웃) 한 다음 변경 사항을 추가 (커밋)하면 비슷하게 축복받습니다. CVS, Subversion, ClearCase, Perforce, VisualSourceSafe 및 기타 모든 CVCS의 유일한 실제 차이점은 각 제품이 제공하는 워크 플로우, 성능 및 통합입니다.
분산 형 VCS 시스템은 한 저장소가 다른 저장소만큼 좋으며 한 저장소에서 다른 저장소로 병합되는 것은 다른 형태의 통신 일 뿐이라는 의도로 설계되었습니다. 어떤 저장소를 신뢰해야하는지에 대한 의미 론적 가치는 소프트웨어 자체가 아닌 프로세스에 의해 외부에서 부과됩니다.
한 유형 또는 다른 유형을 사용하는 것 사이의 진정한 선택은 조직적인 것입니다. 프로젝트 나 조직이 중앙 집중식 제어를 원하는 경우 DVCS는 시작이 아닙니다. 개발자가 중앙 저장소에 대한 보안 광대역 연결없이 국가 / 전세계에서 작업 할 것으로 예상되는 경우 DVCS가 아마도 당신의 구원이 될 것입니다. 둘 다 필요하면 fsck'd입니다.
분산 시스템이 신뢰할 수있는 복사본을 허용하지 않는다고 생각하는 사람들에게는 분산 시스템에 신뢰할 수있는 복사본이있는 곳이 많이 있다는 점에 유의하십시오. 완벽한 예는 Linus의 커널 트리 일 것입니다. 물론 많은 사람들이 자신의 나무를 가지고 있지만 거의 모두가 Linus의 나무로 흐릅니다.
그것은 분산 된 SCM이 다른 일을하는 많은 개발자들에게만 유용하다고 생각하는데 사용했지만 최근에는 중앙 집중식 저장소가 분산 저장소를 더 잘 할 수 있다고 결정했습니다.
예를 들어, 자신의 개인 프로젝트에서 일하는 솔로 개발자라고 가정 해보십시오. 중앙 저장소는 당연한 선택 일 수 있지만이 시나리오를 고려하십시오. 네트워크 액세스 (비행기, 공원 등)에서 멀리 떨어져 있고 프로젝트 작업을 원합니다. 로컬 사본을 가지고 있으므로 제대로 작업 할 수 있지만 한 기능을 완료하고 다른 기능으로 이동하거나 수정해야 할 버그를 찾았 기 때문에 실제로 커밋하고 싶습니다. 요점은 중앙 집중식 리포지토리를 사용하면 모든 변경 사항을 함께 매쉬하고 비논리적 변경 집합으로 커밋하거나 나중에 수동으로 분할하게된다는 것입니다.
분산 리포지토리를 사용하면 평소와 같이 업무를 수행하고 커밋하고 계속 진행합니다. 다시 넷 액세스 권한을 갖게되면 "하나의 진정한 리포지토리"로 푸시하고 아무것도 변경되지 않습니다.
분산 리포지토리에 대한 다른 좋은 점은 말할 것도없이 항상 전체 기록을 사용할 수 있습니다. 네트워크에서 멀리 떨어져있을 때 개정 로그를 확인해야합니까? 버그가 어떻게 도입되었는지보기 위해 소스에 주석을 달아야합니까? 분산 저장소로 모두 가능합니다.
분산 형 vs 중앙 집중 형이 소유권이나 권위있는 복사본 또는 이와 유사한 것이라고 믿지 마십시오. 분산 된 현실은 SCM 진화의 다음 단계입니다.
실제로 비교는 아니지만 큰 프로젝트가 사용하는 것은 다음과 같습니다.
Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...
CVS
CVS
Linux 커널, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...
Mozilla 및 Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...
Emacs, Apt, Mailman, MySQL, Squid 등도 Ubuntu 내에서 홍보되었습니다.
ghc, ion, xmonad, ... Haskell 커뮤니티에서 인기가 있습니다.
SQLite
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)은 해당 액세스를 제한하려고하므로이를 단순하게 만듭니다. 그러나 제 생각에는 회사 문화에 충분한 역기능이 있다면 전 세계의 버전 관리가 소스 코드 유출을 방지하는 데 도움이되지 않습니다.
올바른 SCM을 검색하는 동안 다음 링크가 큰 도움이되었습니다.
어느 정도까지는 두 가지 계획이 동일합니다.
그렇긴하지만, DVCS가 전통적으로 매우 잘 수행하고 대부분의 중앙 집중식 VCS가 약간의 해시를 만드는 몇 가지가 있습니다. 이들 중 가장 중요한 것은 아마도 분기 일 것입니다. DVCS를 사용하면 저장소를 분기하거나 더 이상 필요하지 않은 분기를 병합하기가 매우 쉬워지며 그렇게하는 동안 기록을 추적 할 수 있습니다. 중앙 집중식 체계가이 문제를 겪을 특별한 이유는 없지만 역사적으로 아무도 제대로 이해하지 못한 것 같습니다. 그것이 실제로 당신에게 문제인지 여부는 개발을 어떻게 구성 할 것인지에 달려 있지만 많은 사람들에게 그것은 중요한 고려 사항입니다.
DVCS의 다른 장점은 오프라인으로 작업한다는 것입니다. 나는 정말로 그것을 많이 사용하지 않았습니다. 저는 주로 사무실 (저장소가 로컬 네트워크에 있음) 또는 집 (따라서 ADSL이 있음)에서 개발을합니다. 여행하는 동안 랩톱에서 많은 개발을 수행하는 경우 이것은 더 많은 고려 사항이 될 수 있습니다.
실제로 DVCS와 관련된 문제는 많지 않습니다. 사람들이 조용히하는 경향이 약간 더 큽니다. 왜냐하면 밀지 않고 커밋 할 수 있고 개인적으로 물건을 다듬는 것이 쉽기 때문입니다.하지만 그 외에는 문제가 많지 않았습니다. 이는 일반적으로 패치 트레이딩 개발 모델에 익숙한 많은 오픈 소스 개발자가 있지만 들어오는 폐쇄 소스 개발자도 합리적으로 빠르게 상황을 파악하기 때문일 수 있습니다.
나는 수년 동안 Subversion을 사용해 왔으며 정말 행복했습니다.
그런 다음 GIT 버즈가 시작되었고 나는 그것을 테스트해야했습니다. 저에게있어 주요 판매 포인트는 분기였습니다. 오 소년. 이제 더 이상 내 저장소를 정리할 필요가 없으며 몇 가지 버전으로 돌아가거나 Subversion을 사용할 때했던 어리석은 일을 할 필요가 없습니다. dvcs에서는 모든 것이 저렴합니다. 나는 화석과 git 만 시도했지만 perforce, cvs 및 subversion을 사용했으며 dvcs 모두 정말 저렴한 분기 및 태깅이있는 것처럼 보입니다. 더 이상 모든 코드를 한쪽으로 복사 할 필요가 없으므로 병합이 간단합니다.
모든 dvcs는 중앙 서버로 설정할 수 있지만 얻을 수있는 것은 무엇보다도
Linus가 방금 한 일을 설명하기 위해 두 개 이상의 문장을 사용해야하는 경우에는 너무 많은 일을하고있는 것처럼 원하는 작은 변경 사항을 체크인 할 수 있습니다. 누구나 엄청난 양의 데이터를 다운로드하지 않고도 로컬에서 코드, 분기, 병합, 복제 및 테스트를 수행 할 수 있습니다. 그리고 최종 변경 사항을 중앙 서버로 푸시하기 만하면됩니다.
네트워크 없이도 작업 할 수 있습니다.
즉, 버전 제어를 사용하는 것은 항상 좋은 것입니다. dvcs를 사용하는 것이 더 저렴하고 (KB 및 대역폭) 사용하는 것이 더 재미 있다고 생각합니다.
Git 체크 아웃 : http://git-scm.com/
Fossil 체크 아웃 : http://www.fossil-scm.org
Mercurial 체크 아웃 : https://www.mercurial-scm.org
이제 저는 dvcs 시스템 만 추천 할 수 있으며 중앙 서버를 쉽게 사용할 수 있습니다.
(명백한 대역폭 문제를 제외하고) 주요 문제는 소유권 입니다.
즉, 다른 (지리적) 사이트가 다른 사이트와 동일한 요소에서 작동하지 않도록해야합니다.
이상적으로이 도구는 파일, 브랜치 또는 저장소에 소유권을 할당 할 수 있습니다.
이 답변의 의견에 대답하기 위해, 당신은 정말 도구가 무엇을 소유하고있는 사람을 말하고 싶어하고, 다음 먼 사이트 (전화, IM 또는 메일을 통해) 통신합니다.
만약 당신이 소유권 메커니즘이 없다면 ... 당신은 "통신"할 것이다. 그러나 종종 너무 늦게;)
요즘 모두가 DVCS가 얼마나 우월한 지에 대한 시류에 참여하고 있지만 Craig의 의견은 중요합니다. DVCS에서 각 사람은 지부의 전체 역사를 가지고 있습니다. 많은 바이너리 파일 (예 : 이미지 파일 또는 FLA)로 작업하는 경우 엄청난 양의 공간이 필요하며 diff를 수행 할 수 없습니다.
단독 개발자 시나리오에서도 분산 SCM의 또 다른 장점은 많은 사람들과 마찬가지로 작업중인 컴퓨터가 두 대 이상인 경우입니다.
일반적인 스크립트 세트가 있다고 가정 해 보겠습니다. 작업하는 각 시스템에 복제본이있는 경우 요청시 스크립트를 업데이트하고 변경할 수 있습니다. 다음을 제공합니다.
중앙 집중식 시스템이 개발을 위해 별도의 분기를 사용하는 것을 반드시 막지는 않습니다. 코드베이스의 실제 복사본이 하나 일 필요는 없습니다. 오히려 다른 개발자 나 팀이 다른 브랜치를 가질 수 있고, 레거시 브랜치가 존재할 수 있습니다.
일반적으로 리포지토리가 중앙에서 관리된다는 것을 의미합니다. 그러나 이는 백업 할 위치가 하나 뿐이고 스토리지를 관리 할 위치가 하나뿐임을 의미하므로 유능한 IT 부서가있는 회사에서는 일반적으로 이점입니다.