이 질문은 투명한 복제 에 대해 묻지 만 사람들이 투명성에 매달리고 있기 때문에 아직 답변이없는 것 같습니다. 복제에 중점을두기 위해 투명성을 제쳐 놓을 자유를 드리겠습니다. 나중에 투명성을 다루거나 실제로 DVCS에서 그다지 중요하다고 생각하지는 않습니다.
먼저 DVCS에서 리포지토리가 작동하는 방식에 대한 몇 가지 핵심 사항을 설명하겠습니다. (나는 Mercurial에 가장 익숙하므로 예제로 사용할 것이지만, 내가 말하는 모든 것은 git도 마찬가지라고 생각합니다.)
A. DVCS에서 모든 클론은 원본과 동일한 파일 내용과 기록을 포함합니다.
리포지토리를 올바르게 동기화하면 일반적인 DVCS 변경 전파 작업 (복제, 푸시, 풀) 및 일반 리포지토리를 사용하여 복제 시스템을 구축 할 수 있습니다.
B. 새로운 변경 사항은 원래 위치로 전파 될 필요가 없습니다.
특히 특정 리포지토리에서 변경 내용을 가져 와서 내 자신의 일부 변경 사항을 추가하는 경우 내 변경 사항이 해당 특정 리포지토리로 되돌아 갈 필요가 없습니다. 그들은 다른 곳으로 갈 수 있습니다. 이것의 유용성은 아래에 보여줄 예제에서 분명 해져야합니다.
C. 변경은 푸시 또는 풀을 통해 전파 될 수 있습니다.
중앙 집중식 시스템에서는 새로운 변경 사항이 거의 리포지토리로 푸시 될 수 있습니다. DVCS에서는 다양한 변경 전파 토폴로지를 설정할 수 있으며 그 중 일부는 풀링 만 포함합니다. 이는 설정에서 더 많은 유연성을 제공합니다.
예
논의를 위해 분산 된 팀이 duke.de, duke.us, duke.cn 및 duke.mx 도메인의 시스템을 사용하고 duke.de가 "축복 된"저장소를 원하는 곳이라고 가정합니다. 이러한 가정을 감안할 때 위의 세 가지 주요 DVCS 요점을 염두에두고 설정할 수있는 여러 가지 토폴로지의 예를 몇 가지 설명하겠습니다.
0. 중앙 집중식 푸시 모델
hg.duke.de에서 단일 리포지토리를 보유하고 모든 위치의 개발자가 여기에서 복제하고 끌어서 변경 사항을 푸시하도록하십시오. 이것은 독일의 사람들에게는 효과가 있을지 모르지만, 세계 다른 지역의 사람들에게는 문제가 될 것입니다. 모든 복제, 풀 및 푸시 작업은 느린 장거리 네트워크 링크를 통과합니다. 이것은 중앙 집중식 시스템과 마찬가지로 DVCS를 사용하고 있습니다. 이것이 해결하려는 문제입니다.
1. 복제를 통한 중앙 집중식 푸시
hg.duke.de에서 축복받은 저장소를 가지고 hg.duke.cn, hg.duke.mx 및 hg.duke.us에 복제본을 두십시오. 개발자는 로컬 복제본에서 복제하여 hg.duke.de로 변경 사항을 푸시합니다. hg.duke.de에 새로운 변경 사항이 나타날 때마다 변경 사항이 복제본으로 전파되는 후크가 실행됩니다. 그렇지 않으면 복제본은 읽기 전용이므로 병합이나 충돌이 발생하지 않습니다.
예를 들어 멕시코의 개발자 인 경우 hg.duke.mx에서 복제하지만 hg.duke.de로 변경 사항을 푸시합니다. 변경 사항을 푸시하기 전에 다른 변경 사항이 hg.duke.de로 푸시되면 푸시가 차단됩니다. 다른 변경 사항은 hg.duke.mx에 복제되므로 이러한 변경 사항을 로컬로 가져 와서 병합 한 다음 hg.duke.de로 다시 푸시하려고합니다.
큰 클론 작업은 모두 로컬에서 수행되므로 일부 장점이 있습니다. 변경 사항이 비교적 자주 적용되지 않고 증분 변경은 일반적으로 매우 작기 때문에 다른 위치에서 중앙 저장소로 푸시하는 것은 그리 나쁘지 않을 수 있습니다. 특히 수은은 전체 파일과 기록이 아닌 압축 된 diff를 보냅니다.
Mercurial에서는 .hg/hgrc파일에 다음과 같은 것을 넣어 로컬 리포지토리를 설정하여 한 위치에서 다른 위치로 푸시 할 수 있습니다.
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. 단순 풀 모델
축복받은 저장소로 hg.duke.de를 사용하고 복제본으로 다른 것을 복제하여 푸시 대신 변경 사항을 전파 할 수 있습니다. 개발자는 평소와 같이 로컬 복제본을 복제하고 가져옵니다. 변경이 준비되면 개발자는 일부 중앙 서비스에 풀 요청을 제출하여 개발자의 리포지토리에서 hg.duke.de로 가져옵니다. 병합을위한 정책을 수립해야합니다. 예를 들어, 병합 충돌이있는 경우 개발자가 로컬 복제본에서 가져 와서 끌어 오기 요청을 가져 와서 다시 제출하도록 요청이 거부 될 수 있습니다.
이 접근 방식은 변경 사항이 전파되는 동안 개발자를 기다리지 않는 이점이 있습니다. 물론 개발자는 풀 요청이 수행 될 때까지 기다려야하지만 최소한 그 시간 동안 추가 변경 작업을 수행 할 수 있습니다.
변형
적용 할 수있는 변형이 많이 있습니다.
풀 요청 제출은 코드 검토를위한 완벽한 시간입니다. 변경 사항은 모든 사람이 사용할 수 있다는 의미에서 게시되지만 아직 축복받은 저장소에 통합되지 않았습니다.
풀 요청은 수동 또는 일부 자동 시스템에 의해 수행 될 수 있습니다. 풀 요청을 처리하면 변경 사항을 축복 된 저장소에 직접 병합하지 않고 빌드 및 테스트주기가 수행되는 임시 준비 영역으로 병합 할 수 있습니다. 모든 테스트를 통과 한 후에야 변경 세트가 축복받은 저장소에 통합되었습니다.
푸시 모델에 더 익숙한 사용자는 복제본과 함께 각 위치에 로컬 스테이징 저장소를 설정하려고 할 수 있습니다 (예 : hg-stage.duke.mx, hg-stage.duke.cn 등). 그러나 개발자가 다른 로컬 변경 사항과 병합해야 할뿐만 아니라 준비 저장소의 변경 사항을 축복 된 저장소에 병합해야 할 책임이 있습니다. 그러나 올바른 환경에서 작동 할 수 있으며 자동화를 통해 도움을받을 수 있습니다.
"투명도"
이제 투명한 복제 문제입니다.
위의 시나리오를 감안할 때 투명한 복제가 필요하지 않습니다. 모든 리포지토리는 모든 사람에게 공개되며 로컬 복제본에서 당김 / 복제하고 축복 된 리포지토리 또는 로컬 스테이징 영역으로 푸시하는 규칙이 있습니다.
투명성을 원한다면 사람들이 위치에 따라 DNS 검색 도메인을 설정하도록 할 수 있습니다. 로컬 복제 및 준비 저장소는 단순히 "hg"및 "hg-stage"라고하며 DNS 설정은이를 중국의 개발자를 위해 hg.duke.cn 및 hg-stage.duke.cn으로 해결합니다. 다른 위치의 개발자. 그러나 이것은 약간의 마술이며 혼란 스러울 수 있으며 실제로 많은 것을 추가한다고 생각하지 않습니다.
이것이 귀하의 질문에 답변되기를 바랍니다. 나는 그 반응에 대해 많은 자유를 얻었지만, 위에서 설명한 기술을 사용하여 상황을 해결할 수있는 것처럼 보입니다.