คำถามนี้ถามเกี่ยวกับการจำลองแบบโปร่งใสและฉันสงสัยว่ายังไม่มีคำตอบเพราะคนอาจจะถูกแขวนบนความโปร่งใส ฉันจะให้อิสระในการตั้งค่าความโปร่งใสสำหรับช่วงเวลาที่จะมุ่งเน้นไปที่การจำลองแบบ ฉันจะจัดการกับความโปร่งใส (หรือกลเม็ดเด็ดพราย) ในภายหลังและในความเป็นจริงฉันไม่คิดว่ามันเป็นสิ่งสำคัญใน DVCS
ก่อนอื่นให้ฉันใช้ประเด็นสำคัญสองสามข้อเกี่ยวกับวิธีที่ที่เก็บข้อมูลทำงานใน DVCS (ฉันคุ้นเคยกับ Mercurial มากที่สุดนั่นคือสิ่งที่ฉันจะใช้เป็นตัวอย่าง แต่ฉันเชื่อว่าทุกอย่างที่ฉันพูดก็เป็นจริงเช่นเดียวกันกับ git)
A. ใน DVCS โคลนใด ๆ มีเนื้อหาไฟล์และประวัติเหมือนกับต้นฉบับ
ให้คุณรักษา repos อย่างถูกต้องซึ่งหมายความว่าคุณสามารถใช้การดำเนินการเผยแพร่การเปลี่ยนแปลง DVCS สามัญ (โคลนผลักดันดึง) และ repos สามัญเพื่อสร้างระบบการจำลอง
B. การเปลี่ยนแปลงใหม่ไม่จำเป็นต้องแพร่กระจายไปยังที่ที่พวกเขามา
โดยเฉพาะอย่างยิ่งถ้าฉันต้องได้รับการเปลี่ยนแปลงจาก repo เฉพาะและเพิ่มการเปลี่ยนแปลงบางอย่างของฉันเองการเปลี่ยนแปลงของฉันไม่จำเป็นต้องกลับไปที่ repo นั้น พวกเขาสามารถไปที่อื่น อรรถประโยชน์นี้ควรชัดเจนจากตัวอย่างที่ฉันจะแสดงด้านล่าง
C. การเปลี่ยนแปลงสามารถแพร่กระจายได้ด้วยการกดหรือดึง
ในระบบรวมศูนย์การเปลี่ยนแปลงใหม่สามารถทำได้ค่อนข้างมาก (ฉันคิดว่า) ถูกผลักเข้าไปใน repo เท่านั้น ใน DVCS เป็นไปได้ที่จะตั้งค่าโทโพโลยีการเปลี่ยนแปลงที่หลากหลายซึ่งบางอันเกี่ยวข้องกับการดึงเท่านั้น สิ่งนี้จะช่วยเพิ่มความยืดหยุ่นในการตั้งค่า
ตัวอย่าง
เพื่อการอภิปรายสมมติว่าทีมงานกระจายของคุณใช้ระบบในโดเมน duke.de, duke.us, duke.cn และ duke.mx และยิ่งไปกว่านั้น duke.de คือที่ที่เราต้องการให้ repo "มีความสุข" ด้วยสมมติฐานเหล่านี้ให้ฉันจัดทำตัวอย่างของทอพอโลยีที่แตกต่างกันที่คุณสามารถตั้งค่าโดยคำนึงถึงจุดสำคัญสามประการของ DVCS ด้านบน
0. โมเดลการผลักจากส่วนกลาง
มี repo หนึ่งรายการที่ hg.duke.de และให้ผู้พัฒนาในทุกสถานที่ทำการโคลนและดึงจากที่นี่และผลักดันการเปลี่ยนแปลงที่นี่ สิ่งนี้อาจใช้ได้ผลกับคนในประเทศเยอรมนี แต่อาจเป็นปัญหาสำหรับผู้คนในส่วนอื่น ๆ ของโลก การโคลนการดึงและการผลักทั้งหมดจะผ่านการเชื่อมโยงเครือข่ายระยะไกลที่ช้า นี่ใช้ DVCS เหมือนระบบรวมศูนย์ นี่คือปัญหาที่คุณพยายามแก้ไข
1. การผลักดันจากส่วนกลางด้วยการจำลองแบบ
มี repo ที่จำเริญที่ hg.duke.de และมี replicas ที่ hg.duke.cn, hg.duke.mx และ hg.duke.us นักพัฒนาโคลนจากเรพพลิกาท้องถิ่นและผลักดันการเปลี่ยนแปลงไปยัง hg.duke.de เมื่อใดก็ตามที่มีการเปลี่ยนแปลงใหม่ปรากฏใน hg.duke.de จะมีการเรียกใช้ hook ที่แพร่กระจายไปยังเรพลิกา แบบจำลองนั้นเป็นแบบอ่านอย่างเดียวดังนั้นจะไม่มีการรวมหรือความขัดแย้งใด ๆ
ตัวอย่างเช่นหากฉันเป็นนักพัฒนาซอฟต์แวร์ในเม็กซิโกฉันจะลอกแบบจาก hg.duke.mx แต่ผลักดันการเปลี่ยนแปลงไปยัง hg.duke.de หากมีการผลักดันการเปลี่ยนแปลงอื่น ๆ ใน hg.duke.de ก่อนที่ฉันจะสามารถผลักดันการเปลี่ยนแปลงการผลักของฉันจะถูกบล็อก การเปลี่ยนแปลงอื่น ๆ จะได้รับการจำลองแบบเป็น hg.duke.mx ดังนั้นฉันจะดึงการเปลี่ยนแปลงเหล่านี้ในเครื่องรวมแล้วลองเปลี่ยนเป็น hg.duke.de อีกครั้ง
สิ่งนี้ควรให้ประโยชน์บางอย่างเนื่องจากการดำเนินการโคลนใหญ่เสร็จสิ้นภายในเครื่อง การผลักดันไปยัง repo ส่วนกลางในตำแหน่งอื่นอาจไม่เลวร้ายนักเนื่องจากการเปลี่ยนแปลงมีการผลักกันไม่บ่อยนักการเปลี่ยนแปลงที่เพิ่มขึ้นนั้นโดยทั่วไปจะมีขนาดค่อนข้างเล็ก (Mercurial โดยเฉพาะส่งส่วนต่างที่บีบอัดไม่ใช่ไฟล์ทั้งหมดและประวัติ)
ใน Mercurial คุณสามารถตั้งค่า repo ภายในเครื่องเพื่อดึงจากตำแหน่งหนึ่งและดันไปอีกที่หนึ่งโดยใส่บางอย่างดังต่อไปนี้ใน.hg/hgrcไฟล์:
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. แบบดึงง่าย
ดำเนินการต่อกับ hg.duke.de ในฐานะ repo ที่มีความสุขและอื่น ๆ เป็นแบบจำลองเราสามารถเผยแพร่การเปลี่ยนแปลงผ่านการดึงแทนการกด นักพัฒนาโคลนและดึงจากแบบจำลองในเครื่องตามปกติ เมื่อการเปลี่ยนแปลงพร้อมผู้พัฒนาส่งคำขอดึงไปยังบริการส่วนกลางบางอย่างซึ่งดึงจาก repo ของผู้พัฒนาไปยัง hg.duke.de จะต้องมีการกำหนดนโยบายสำหรับการรวม ตัวอย่างเช่นหากมีข้อขัดแย้งในการผสานคำขออาจถูกปฏิเสธต้องการให้นักพัฒนาดึง (จากโลคัลจำลอง) รวมและส่งคำร้องขอให้ส่งอีกครั้ง
วิธีการนี้มีข้อได้เปรียบที่จะไม่ทำให้นักพัฒนารอในขณะที่มีการเผยแพร่การเปลี่ยนแปลง แน่นอนผู้พัฒนายังต้องรอคำขอดึงที่จะดำเนินการ แต่อย่างน้อยเขาหรือเธอสามารถทำงานกับการเปลี่ยนแปลงเพิ่มเติมในช่วงเวลานั้น
รูปแบบ
มีความหลากหลายของรูปแบบที่สามารถนำไปใช้
การส่งคำขอดึงเป็นเวลาที่เหมาะสำหรับการตรวจสอบรหัส การเปลี่ยนแปลงมีการเผยแพร่ในแง่ที่ว่าทุกคนสามารถใช้งานได้ แต่ยังไม่ได้รวมเข้ากับ repo ที่ได้รับพร
คำขอดึงสามารถดำเนินการได้ด้วยตนเองหรือโดยระบบอัตโนมัติบางระบบ การประมวลผลคำขอดึงอาจไม่รวมการเปลี่ยนแปลงลงใน repo ที่มีความสุขโดยตรง แต่เข้าสู่พื้นที่การแสดงชั่วคราวซึ่งเป็นการสร้างและทดสอบวงจร หลังจากผ่านการทดสอบทั้งหมดแล้วชุดการเปลี่ยนแปลงจะรวมเข้ากับ repo ที่ได้รับพร
ผู้ที่มีความสะดวกสบายมากขึ้นกับแบบจำลองการกดอาจต้องการตั้งค่า repo การจัดเตรียมแบบโลคัลในแต่ละตำแหน่งควบคู่ไปกับแบบจำลองเช่น hg-stage.duke.mx, hg-stage.duke.cn ฯลฯ สิ่งนี้ต้องใช้งานอีกเล็กน้อย แม้ว่าในฐานะนักพัฒนาไม่เพียง แต่ต้องรวมกับการเปลี่ยนแปลงในท้องถิ่นอื่น ๆ แต่ใครบางคนจะต้องรับผิดชอบในการรวมการเปลี่ยนแปลงจาก repos แสดงละครเป็น repo จำเริญ สิ่งนี้สามารถทำงานได้ภายใต้สถานการณ์ที่เหมาะสมแม้ว่าและสามารถช่วยได้โดยอัตโนมัติ
"ความโปร่งใส"
ตอนนี้ปัญหาการจำลองแบบโปร่งใส
จากสถานการณ์ข้างต้นฉันไม่เห็นความจำเป็นในการจำลองแบบโปร่งใส ทุก repos สามารถมองเห็นได้ทุกคนและมีการประชุมสำหรับการดึง / การโคลนจากแบบจำลองในท้องถิ่นและผลักดันไปยัง repo ที่มีความสุขหรือพื้นที่การแสดงละครท้องถิ่น
หากคุณต้องการความโปร่งใสคุณสามารถให้คนตั้งค่าโดเมนการค้นหา DNS ตามที่ตั้งของพวกเขา Repos และ staging repos ในท้องถิ่นจะเรียกว่า "hg" และ "hg-stage" และการตั้งค่า DNS จะแก้ไขสิ่งเหล่านี้เป็น hg.duke.cn และ hg-stage.duke.cn สำหรับนักพัฒนาในประเทศจีนและตามลำดับสำหรับ นักพัฒนาซอฟต์แวร์ในที่อื่น ๆ แต่นี่เป็นเวทย์มนตร์เล็กน้อยและอาจทำให้สับสนและฉันไม่คิดว่ามันจะเพิ่มอะไรมากมาย
ฉันหวังว่านี้ตอบคำถามของคุณ. ฉันใช้เสรีภาพในการตอบสนองเป็นจำนวนมาก แต่ดูเหมือนว่าสถานการณ์ของคุณสามารถแก้ไขได้โดยใช้เทคนิคที่ฉันได้อธิบายไว้ข้างต้น