ความแตกต่างที่สำคัญคือ (ตามที่ได้กล่าวไปแล้วในคำตอบอื่น ๆ ) CVS คือระบบควบคุมเวอร์ชันส่วนกลาง (เก่า) ในขณะที่ Git ได้รับการแจกจ่าย
แต่แม้ว่าคุณจะใช้การควบคุมเวอร์ชันสำหรับนักพัฒนาคนเดียวในเครื่องเดียว (บัญชีเดียว) ความแตกต่างระหว่าง Git และ CVS มีอยู่เล็กน้อย:
การตั้งค่าพื้นที่เก็บข้อมูล Git จัดเก็บที่เก็บใน.gitไดเร็กทอรีในไดเร็กทอรีบนสุดของโปรเจ็กต์ของคุณ CVS ต้องการการตั้งค่า CVSROOT ซึ่งเป็นศูนย์กลางสำหรับจัดเก็บข้อมูลการควบคุมเวอร์ชันสำหรับโครงการต่างๆ (โมดูล) ผลที่ตามมาของการออกแบบสำหรับผู้ใช้คือการนำเข้าซอร์สที่มีอยู่ไปยังการควบคุมเวอร์ชันนั้นทำได้ง่ายเพียงแค่ "git init && git add. && git คอมมิต" ใน Git ในขณะที่CVS มีความซับซ้อนกว่า
การดำเนินงานของอะตอม เนื่องจาก CVS ในตอนเริ่มต้นเป็นชุดของสคริปต์รอบ ๆ ระบบควบคุมเวอร์ชัน RCS ต่อไฟล์การกระทำ (และการดำเนินการอื่น ๆ ) จึงไม่ใช่อะตอมใน CVS หากการดำเนินการบนที่เก็บถูกขัดจังหวะตรงกลางที่เก็บสามารถปล่อยให้อยู่ในสถานะที่ไม่สอดคล้องกัน ใน Git การดำเนินการทั้งหมดเป็นแบบปรมาณู: ไม่ว่าจะประสบความสำเร็จโดยรวมหรือล้มเหลวโดยไม่มีการเปลี่ยนแปลงใด ๆ
การเปลี่ยนแปลง การเปลี่ยนแปลง CVS เป็นไปตามไฟล์ในขณะที่การเปลี่ยนแปลง (คอมมิต) ใน Git จะอ้างถึงโปรเจ็กต์ทั้งหมดเสมอ นี้เป็นสิ่งสำคัญมากปรับเปลี่ยนกระบวนทัศน์ ผลที่ตามมาประการหนึ่งก็คือมันง่ายมากใน Git ที่จะเปลี่ยนกลับ (สร้างการเปลี่ยนแปลงที่เลิกทำ) หรือเลิกทำการเปลี่ยนแปลงทั้งหมด ผลลัพธ์อื่น ๆ ก็คือใน CVS นั้นง่ายต่อการชำระเงินบางส่วนในขณะที่ปัจจุบันเป็นไปไม่ได้ใน Git ความจริงที่ว่าการเปลี่ยนแปลงเป็นต่อไฟล์รวมกลุ่มกันทำให้เกิดการประดิษฐ์รูปแบบ GNU Changelog สำหรับส่งข้อความใน CVS ผู้ใช้ Git ใช้ (และเครื่องมือ Git บางตัวคาดหวัง) รูปแบบที่แตกต่างกันโดยมีบรรทัดเดียวอธิบายการเปลี่ยนแปลง (สรุป) ตามด้วยบรรทัดว่างตามด้วยคำอธิบายโดยละเอียดเพิ่มเติมของการเปลี่ยนแปลง
การตั้งชื่อการแก้ไข / หมายเลขรุ่น มีปัญหาอื่นที่เกี่ยวข้องกับการเปลี่ยนแปลง CVS ต่อไฟล์: หมายเลขเวอร์ชัน (ดังที่คุณเห็นบางครั้งในการขยายคีย์เวิร์ดดูด้านล่าง) เช่น 1.4 แสดงจำนวนไฟล์ที่กำหนด ใน Git แต่ละเวอร์ชันของโปรเจ็กต์โดยรวม (แต่ละคอมมิต) มีชื่อเฉพาะที่กำหนดโดย ID SHA-1 โดยปกติ 7-8 อักขระแรกจะเพียงพอที่จะระบุคอมมิต (คุณไม่สามารถใช้รูปแบบการกำหนดหมายเลขอย่างง่ายสำหรับเวอร์ชันในระบบควบคุมเวอร์ชันแบบกระจายซึ่งต้องใช้สิทธิ์ในการกำหนดหมายเลขกลาง) ใน CVS มีหมายเลขเวอร์ชันหรือชื่อสัญลักษณ์ที่อ้างถึงสถานะของโปรเจ็กต์โดยรวมที่คุณใช้แท็ก; เช่นเดียวกับใน Git หากคุณต้องการใช้ชื่อเช่น 'v1.5.6-rc2' สำหรับบางเวอร์ชันของโปรเจ็กต์ ... แต่แท็กใน Git นั้นใช้งานง่ายกว่ามาก
แขนงง่าย สาขาใน CVS อยู่ในความคิดของฉันซับซ้อนเกินไปและยากที่จะจัดการ คุณต้องแท็กสาขาเพื่อให้มีชื่อสำหรับสาขาที่เก็บทั้งหมด (และถึงแม้จะล้มเหลวในบางกรณีถ้าฉันจำไม่ผิดเนื่องจากการจัดการต่อไฟล์) นอกจากนี้ข้อเท็จจริงที่ว่า CVS ไม่มีการติดตามการผสานดังนั้นคุณต้องจำหรือติดแท็กการผสานและจุดแยกด้วยตนเองและจัดหาข้อมูลที่ถูกต้องสำหรับ "cvs update -j" เพื่อรวมสาขาด้วยตนเองและทำให้มีการแยกสาขา เป็นเรื่องยากที่จะใช้โดยไม่จำเป็น ใน Git การสร้างและการรวมสาขานั้นง่ายมาก Git จะจดจำข้อมูลที่จำเป็นทั้งหมดด้วยตัวเอง (ดังนั้นการรวมสาขาจึงทำได้ง่ายเหมือนกับ "git merge branchchname ") ... เพราะการพัฒนาแบบกระจายจะนำไปสู่หลายสาขาโดยธรรมชาติ
ซึ่งหมายความว่าคุณสามารถใช้สาขาหัวข้อกล่าวคือพัฒนาคุณลักษณะที่แยกจากกันในหลายขั้นตอนในสาขาคุณลักษณะที่แยกจากกัน
เปลี่ยนชื่อ (และสำเนา) การติดตาม CVS ไม่รองรับการเปลี่ยนชื่อไฟล์และการเปลี่ยนชื่อด้วยตนเองอาจทำลายประวัติเป็นสองส่วนหรือทำให้ประวัติไม่ถูกต้องซึ่งคุณไม่สามารถกู้คืนสถานะของโปรเจ็กต์ได้อย่างถูกต้องก่อนที่จะเปลี่ยนชื่อ Git ใช้การตรวจจับการเปลี่ยนชื่อฮิวริสติกโดยพิจารณาจากความคล้ายคลึงกันของเนื้อหาและชื่อไฟล์ (โซลูชันนี้ใช้ได้ดีในทางปฏิบัติ) คุณยังสามารถขอตรวจจับการคัดลอกไฟล์ ซึ่งหมายความว่า:
- เมื่อตรวจสอบการคอมมิตที่ระบุคุณจะได้รับข้อมูลว่าไฟล์บางไฟล์ถูกเปลี่ยนชื่อ
- การรวมอย่างถูกต้องจะพิจารณาการเปลี่ยนชื่อ (ตัวอย่างเช่นหากไฟล์ถูกเปลี่ยนชื่อในสาขาเดียวเท่านั้น)
- "คอมไพล์ตำหนิ" ซึ่ง (ดีกว่า) เทียบเท่ากับ "คำอธิบายประกอบ cvs" ซึ่งเป็นเครื่องมือในการแสดงประวัติเนื้อหาของไฟล์อย่างชาญฉลาดสามารถติดตามการเคลื่อนไหวของโค้ดได้เช่นกันในการเปลี่ยนชื่อ
ไฟล์ไบนารี CVS มีการรองรับไฟล์ไบนารีที่ จำกัด มากเท่านั้น (เช่นรูปภาพ) กำหนดให้ผู้ใช้ทำเครื่องหมายไฟล์ไบนารีอย่างชัดเจนเมื่อเพิ่ม (หรือในภายหลังโดยใช้ "ผู้ดูแลระบบ cvs" หรือผ่านทาง wrapper เพื่อดำเนินการโดยอัตโนมัติตามชื่อไฟล์) เพื่อหลีกเลี่ยงการเปลี่ยนแปลง ไฟล์ไบนารีผ่านการแปลงปลายทางและการขยายคำหลัก Git ตรวจพบไฟล์ไบนารีโดยอัตโนมัติตามเนื้อหาในลักษณะเดียวกับ CNU diff และเครื่องมืออื่น ๆ คุณสามารถลบล้างการตรวจจับนี้ได้โดยใช้กลไก gitattributes ยิ่งไปกว่านั้นไฟล์ไบนารียังปลอดภัยจากการโกงที่ไม่สามารถกู้คืนได้ด้วยค่าเริ่มต้นที่ 'safeecrlf' (และความจริงที่ว่าคุณต้องร้องขอการแปลง end-of-line แม้ว่าสิ่งนี้อาจถูกเปิดโดยค่าเริ่มต้นขึ้นอยู่กับการแจกจ่าย) และคำหลักนั้น (จำกัด ) การขยายเป็นการ 'เลือกใช้' ที่เข้มงวดใน Git
ขยายคำหลัก Git เสนอชุดคำหลักที่ จำกัด มากเมื่อเทียบกับ CVS (โดยค่าเริ่มต้น) นี่เป็นเพราะข้อเท็จจริงสองประการ: การเปลี่ยนแปลงใน Git เป็นไปตามที่เก็บไม่ใช่ต่อไฟล์และ Git หลีกเลี่ยงการแก้ไขไฟล์ที่ไม่เปลี่ยนแปลงเมื่อเปลี่ยนไปใช้ branch อื่นหรือย้อนกลับไปยังจุดอื่นในประวัติ หากคุณต้องการฝังหมายเลขการแก้ไขโดยใช้ Git คุณควรดำเนินการโดยใช้ระบบการสร้างของคุณเช่นทำตามตัวอย่างของสคริปต์ GIT-VERSION-GEN ในซอร์สเคอร์เนลของ Linux และในแหล่ง Git
กระทำแก้ไขเพิ่มเติม เนื่องจากใน VCS แบบกระจายเช่นการเผยแพร่ Git นั้นแยกออกจากการสร้างคอมมิตจึงสามารถเปลี่ยน (แก้ไขเขียนซ้ำ) ส่วนที่ไม่ได้เผยแพร่ของประวัติโดยไม่ทำให้ผู้ใช้รายอื่นไม่สะดวก โดยเฉพาะอย่างยิ่งหากคุณสังเกตเห็นการพิมพ์ผิด (หรือข้อผิดพลาดอื่น ๆ ) ในข้อความคอมมิตหรือข้อผิดพลาดในการคอมมิตคุณสามารถใช้ "คอมมิตคอมมิต --amend" สิ่งนี้เป็นไปไม่ได้ (อย่างน้อยก็ไม่ใช่หากไม่มีการแฮ็กข้อมูลจำนวนมาก) ใน CVS
เครื่องมือเพิ่มเติม Git มีเครื่องมือมากกว่า CVS หนึ่งในสิ่งที่สำคัญกว่านั้นคือ " git bisect " ที่สามารถใช้เพื่อค้นหาการกระทำ (การแก้ไข) ที่ทำให้เกิดข้อบกพร่อง หากการกระทำของคุณมีขนาดเล็กและมีอยู่ในตัวมันควรจะง่ายพอสมควรแล้วที่จะค้นพบว่าจุดบกพร่องอยู่ที่ใด
หากคุณทำงานร่วมกับนักพัฒนารายอื่นอย่างน้อยหนึ่งคนคุณจะพบความแตกต่างระหว่าง Git และ CVS ดังต่อไปนี้:
Commit ก่อนผสาน Git ใช้การกระทำก่อนผสานแทนที่จะใช้เช่น CVS ผสานก่อนคอมมิต (หรืออัปเดตแล้วคอมมิต ) หากในขณะที่คุณกำลังแก้ไขไฟล์กำลังเตรียมพร้อมสำหรับการสร้างคอมมิตใหม่ (การแก้ไขใหม่) มีคนอื่นสร้างคอมมิตใหม่ในสาขาเดียวกันและตอนนี้อยู่ในที่เก็บ CVS บังคับให้คุณอัปเดตไดเร็กทอรีการทำงานของคุณก่อนและแก้ไขข้อขัดแย้งก่อนที่จะอนุญาตให้คุณคอมมิต นี่ไม่ใช่กรณีของ Git ก่อนอื่นคุณยอมรับบันทึกสถานะของคุณในการควบคุมเวอร์ชันจากนั้นรวมการเปลี่ยนแปลงอื่น ๆ ของนักพัฒนา คุณยังขอให้นักพัฒนารายอื่นทำการผสานและแก้ไขข้อขัดแย้งได้
หากคุณต้องการมีประวัติเชิงเส้นและหลีกเลี่ยงการผสานคุณสามารถใช้เวิร์กโฟลว์คอมมิต - ผสาน - แนะนำผ่าน "git rebase" (และ "git pull --rebase") ซึ่งคล้ายกับ CVS ตรงที่คุณเล่นซ้ำการเปลี่ยนแปลงที่ด้านบน ของสถานะที่อัปเดต แต่คุณมักจะกระทำก่อน
ไม่จำเป็นต้องมีที่เก็บส่วนกลางด้วย Git ไม่จำเป็นต้องมีที่ส่วนกลางเดียวที่คุณยอมรับการเปลี่ยนแปลงของคุณ นักพัฒนาแต่ละคนสามารถมีที่เก็บของตัวเอง (หรือที่เก็บที่ดีกว่า: ที่เก็บส่วนตัวที่เขา / เธอทำการพัฒนาและที่เก็บข้อมูลสาธารณะที่เธอ / เขาเผยแพร่ส่วนนั้นที่พร้อม) และพวกเขาสามารถดึง / ดึงข้อมูลจากที่เก็บอื่น ๆ ใน แฟชั่นสมมาตร ในทางกลับกันเป็นเรื่องปกติที่โครงการขนาดใหญ่จะมีที่เก็บส่วนกลางที่กำหนด / เสนอชื่อทางสังคมซึ่งทุกคนดึงมาจาก (รับการเปลี่ยนแปลงจาก)
ในที่สุด Git ก็นำเสนอความเป็นไปได้อื่น ๆ อีกมากมายเมื่อต้องการความร่วมมือกับนักพัฒนาจำนวนมาก ด้านล่างนี้มีความแตกต่างระหว่าง CVS ใน Git สำหรับขั้นตอนความสนใจและตำแหน่งต่างๆในโปรเจ็กต์ (ภายใต้การควบคุมเวอร์ชันโดยใช้ CVS หรือ Git):
lurker หากคุณสนใจที่จะรับการเปลี่ยนแปลงล่าสุดจากโครงการเท่านั้น ( ไม่มีการเผยแพร่การเปลี่ยนแปลงของคุณ ) หรือทำการพัฒนาส่วนตัว (โดยไม่ต้องสนับสนุนโครงการเดิม) หรือคุณใช้โครงการต่างประเทศเป็นพื้นฐานของโครงการของคุณเอง (การเปลี่ยนแปลงเกิดขึ้นในท้องถิ่นและไม่สมเหตุสมผลที่จะเผยแพร่)
Git รองรับการเข้าถึงแบบอ่านอย่างเดียวโดยไม่ระบุชื่อที่ไม่ได้รับการตรวจสอบสิทธิ์ผ่านgit://โปรโตคอลที่มีประสิทธิภาพแบบกำหนดเองหรือหากคุณอยู่เบื้องหลังการบล็อกไฟร์วอลล์DEFAULT_GIT_PORT(9418) คุณสามารถใช้ HTTP ธรรมดาได้
สำหรับวิธีแก้ปัญหาทั่วไปของ CVS (ตามที่ฉันเข้าใจ) สำหรับการเข้าถึงแบบอ่านอย่างเดียวคือบัญชีผู้เยี่ยมชมสำหรับโปรโตคอล 'pserver' บนCVS_AUTH_PORT(2401) ซึ่งมักเรียกว่า "ไม่ระบุชื่อ" และมีรหัสผ่านว่างเปล่า ข้อมูลรับรองจะถูกเก็บไว้ตามค่าเริ่มต้นใน$HOME/.cvspassไฟล์ดังนั้นคุณต้องระบุเพียงครั้งเดียว ยังคงเป็นอุปสรรคเล็กน้อย (คุณต้องรู้ชื่อบัญชีผู้เยี่ยมชมหรือใส่ใจกับข้อความเซิร์ฟเวอร์ CVS) และความรำคาญ
นักพัฒนาสวัสดิการ (ใบมีส่วนร่วม) วิธีหนึ่งในการขยายพันธุ์การเปลี่ยนแปลงในโอเอสจะส่งแพทช์ผ่านทางอีเมล นี่เป็นวิธีแก้ปัญหาที่พบบ่อยที่สุดหากคุณเป็นนักพัฒนาโดยไม่ได้ตั้งใจ (ไม่มากก็น้อย) ส่งการเปลี่ยนแปลงเพียงครั้งเดียวหรือแก้ไขข้อบกพร่องเดียว BTW การส่งแพตช์อาจจะผ่านทางคณะกรรมการตรวจสอบ (ระบบตรวจสอบโปรแกรมแก้ไข) หรือวิธีการที่คล้ายกันไม่ใช่ทางอีเมลเท่านั้น
Git มีเครื่องมือที่ช่วยในกลไกการเผยแพร่ (การเผยแพร่) นี้ทั้งสำหรับผู้ส่ง (ไคลเอนต์) และสำหรับผู้ดูแล (เซิร์ฟเวอร์) สำหรับผู้ที่ต้องการส่งการเปลี่ยนแปลงทางอีเมลมีเครื่องมือ " git rebase " (หรือ "git pull --rebase") สำหรับเล่นซ้ำการเปลี่ยนแปลงของคุณเองที่ด้านบนของเวอร์ชันอัปสตรีมปัจจุบันดังนั้นการเปลี่ยนแปลงของคุณจึงอยู่เหนือเวอร์ชันปัจจุบัน (ใหม่ ) และ " git format-patch " เพื่อสร้างอีเมลที่มีข้อความคอมมิต (และผู้เขียน) เปลี่ยนรูปแบบ (ขยาย) unified diff format (บวก diffstat เพื่อการตรวจสอบที่ง่ายขึ้น) ผู้ดูแลสามารถเปลี่ยนอีเมลดังกล่าวให้เป็นการยืนยันการรักษาข้อมูลทั้งหมดได้โดยตรง (รวมถึงข้อความคอมมิต) โดยใช้ " git am "
CVS ไม่มีเครื่องมือดังกล่าว: คุณสามารถใช้ "cvs diff" / "cvs rdiff" เพื่อสร้างการเปลี่ยนแปลงและใช้โปรแกรมแก้ไข GNU เพื่อใช้การเปลี่ยนแปลง แต่เท่าที่ฉันทราบไม่มีวิธีใดที่จะทำให้การใช้ข้อความคอมมิตโดยอัตโนมัติ CVS มีขึ้นเพื่อใช้ในไคลเอนต์ <-> เซิร์ฟเวอร์แฟชั่น ...
ร้อยโท . หากคุณเป็นผู้ดูแลส่วนที่แยกต่างหากของโปรเจ็กต์ (ระบบย่อย) หรือหากการพัฒนาโปรเจ็กต์ของคุณเป็นไปตามเวิร์กโฟลว์ "เครือข่ายแห่งความไว้วางใจ" ที่ใช้ในการพัฒนาเคอร์เนลลินุกซ์ ... หรือหากคุณมีที่เก็บสาธารณะของคุณเองและการเปลี่ยนแปลงที่คุณ ต้องการเผยแพร่มีขนาดใหญ่เกินไปที่จะส่งทางอีเมลเป็นชุดโปรแกรมแก้ไขคุณสามารถส่งคำขอดึงไปยังผู้ดูแลโครงการ (หลัก) ได้
นี่เป็นโซลูชันเฉพาะสำหรับระบบควบคุมเวอร์ชันกระจายดังนั้น CVS จึงไม่รองรับวิธีการทำงานร่วมกันดังกล่าว มีแม้กระทั่งเครื่องมือที่เรียกว่า "git request-pull" ซึ่งช่วยในการเตรียมอีเมลเพื่อส่งไปยังผู้ดูแลพร้อมกับขอดึงจากที่เก็บของคุณ ขอบคุณ "git bundle" คุณสามารถใช้กลไกนี้ได้โดยไม่ต้องมีที่เก็บสาธารณะด้วยการส่งชุดการเปลี่ยนแปลงทางอีเมลหรือ sneakernet ไซต์โฮสติ้ง Git บางไซต์เช่นGitHubได้รับการสนับสนุนในการแจ้งว่ามีคนทำงาน (เผยแพร่ผลงานบางส่วน) ในโครงการของคุณ (โดยมีเงื่อนไขว่าเขา / เธอใช้ไซต์โฮสติ้ง Git เดียวกัน) และสำหรับ PM-ing คำขอดึง
ผู้พัฒนาหลักได้แก่ ผู้ที่เผยแพร่การเปลี่ยนแปลงของตนโดยตรง (ไปยังที่เก็บหลัก / ที่เก็บตามรูปแบบบัญญัติ) หมวดหมู่นี้กว้างกว่าสำหรับระบบควบคุมเวอร์ชันแบบกระจายเนื่องจากการมีนักพัฒนาหลายคนที่มีสิทธิ์เข้าถึงการเขียนไปยังที่เก็บส่วนกลางไม่ได้เป็นเพียงขั้นตอนการทำงานที่เป็นไปได้ (คุณสามารถมีผู้ดูแลคนเดียวที่ผลักดันการเปลี่ยนแปลงไปยังที่เก็บมาตรฐานชุดของผู้แทน / ผู้ดูแลระบบย่อยที่เขา / เธอใช้ ดึงและนักพัฒนาใบไม้หลากหลายประเภทที่ส่งแพตช์ทางไปรษณีย์ไปยังรายชื่อผู้รับจดหมายของผู้ดูแล / โครงการหรือไปยังผู้แทน / ผู้ใต้บังคับบัญชาคนใดคนหนึ่ง)
ด้วย Git คุณมีทางเลือกในการใช้โปรโตคอล SSH ( โปรโตคอล git ที่ห่อหุ้มด้วย SSH) เพื่อเผยแพร่การเปลี่ยนแปลงด้วยเครื่องมือต่างๆเช่น "git shell" (เพื่อช่วยในการรักษาความปลอดภัย จำกัด การเข้าถึงบัญชีเชลล์) หรือGitosis (เพื่อจัดการการเข้าถึงโดยไม่ต้องแยกบัญชีเชลล์ ) และHTTPSกับ WebDAV พร้อมการตรวจสอบสิทธิ์ HTTP ธรรมดา
ด้วย CVS มีตัวเลือกระหว่างโปรโตคอลpserver ที่ไม่เข้ารหัส (ข้อความธรรมดา) แบบกำหนดเองหรือใช้รีโมตเชลล์ (ซึ่งคุณควรใช้SSHจริงๆ) เพื่อเผยแพร่การเปลี่ยนแปลงของคุณซึ่งสำหรับระบบควบคุมเวอร์ชันส่วนกลางหมายถึงการดำเนินการเปลี่ยนแปลงของคุณ (สร้างคอมมิต) คุณยังสามารถอุโมงค์โปรโตคอล 'pserver' โดยใช้ SSH และมีเครื่องมือของบุคคลที่สามที่ทำให้สิ่งนี้เป็นอัตโนมัติ ... แต่ฉันไม่คิดว่านี่จะง่ายเหมือนเช่น Gitosis
ในระบบควบคุมเวอร์ชันกระจายทั่วไปเช่น Git มีเวิร์กโฟลว์ที่เป็นไปได้ให้เลือกได้กว้างขึ้น ด้วยระบบควบคุมเวอร์ชันส่วนกลางเช่น CVS โดยความจำเป็นคุณต้องแยกความแตกต่างระหว่างผู้ที่มีสิทธิ์เข้าถึงที่เก็บข้อมูลและผู้ที่ไม่มี ... และ CVS ไม่มีเครื่องมือใด ๆ ที่จะช่วยในการยอมรับการมีส่วนร่วม (ผ่านแพตช์) จากผู้ที่ไม่มี กระทำการเข้าถึง
Karl Fogel ในการผลิตซอฟต์แวร์โอเพ่นซอร์สในส่วนเกี่ยวกับการควบคุมเวอร์ชันระบุว่าจะเป็นการดีกว่าที่จะไม่ให้การควบคุมที่เข้มงวดเข้มงวดและเข้มงวดเกินไปในพื้นที่ที่อนุญาตให้ทำการเปลี่ยนแปลงที่เก็บสาธารณะ เป็นการดีกว่ามากที่จะพึ่งพา (สำหรับสิ่งนี้) ในข้อ จำกัด ทางสังคม (เช่นการตรวจสอบโค้ด) มากกว่าข้อ จำกัด ทางเทคนิค ระบบควบคุมเวอร์ชันแจกจ่ายช่วยลด IMHO นั้นให้ดียิ่งขึ้น ...
HTH (หวังว่าจะช่วยได้)