อะไรคือจุดแข็งและจุดอ่อนของ Git, Mercurial และ Bazaar? [ปิด]

คนที่นี่เห็นว่าอะไรเป็นจุดแข็งและจุดอ่อนของ Git, Mercurial และ Bazaar

ในการพิจารณาแต่ละข้อด้วยกันและต่อต้านระบบควบคุมเวอร์ชันเช่น SVN และ Perforce ควรพิจารณาประเด็นใดบ้าง

ในการวางแผนการโอนย้ายจาก SVN ไปยังหนึ่งในระบบควบคุมเวอร์ชันกระจายเหล่านี้คุณจะพิจารณาปัจจัยใดบ้าง

Git นั้นเร็วมากวัดได้ดีและโปร่งใสมากเกี่ยวกับแนวคิดของมัน ข้อเสียของเรื่องนี้ก็คือมันมีช่วงการเรียนรู้ที่ค่อนข้างสูงชัน พอร์ต Win32 พร้อมใช้งาน แต่ไม่ได้เป็นพลเมืองชั้นหนึ่ง Git เปิดเผยแฮชเป็นหมายเลขเวอร์ชันสำหรับผู้ใช้ สิ่งนี้ให้การรับประกัน (ในที่ที่แฮชเดียวอ้างถึงเนื้อหาเดียวกันเสมอผู้โจมตีไม่สามารถแก้ไขประวัติโดยไม่ถูกตรวจพบ) แต่อาจทำให้ผู้ใช้ยุ่งยาก Git มีแนวคิดที่ไม่เหมือนใครในการติดตามเนื้อหาไฟล์แม้ในขณะที่เนื้อหาเหล่านั้นย้ายไปมาระหว่างไฟล์และดูไฟล์เป็นวัตถุระดับแรก แต่ไม่ได้ติดตามไดเรกทอรี ปัญหาเกี่ยวกับ git ก็คือมีการดำเนินการหลายอย่าง (เช่นการรีบูต) ซึ่งทำให้ง่ายต่อการแก้ไขประวัติ (ในความหมาย - เนื้อหาที่อ้างถึงโดยแฮชจะไม่เปลี่ยนแปลง แต่การอ้างอิงถึงแฮชนั้นอาจหายไป) ครูสอนบางคน (รวมตัวเอง) ไม่ชอบมาก

Bazaar นั้นเร็วพอสมควร (เร็วมากสำหรับต้นไม้ที่มีประวัติตื้นเขิน แต่ปัจจุบันมีขนาดไม่ดีกับความยาวประวัติ) และง่ายต่อการเรียนรู้สำหรับผู้ที่คุ้นเคยกับอินเตอร์เฟสบรรทัดคำสั่งของ SCM แบบดั้งเดิม (CVS, SVN และอื่น ๆ ) Win32 ถือเป็นเป้าหมายชั้นหนึ่งโดยทีมพัฒนา มันมีสถาปัตยกรรมแบบเสียบได้สำหรับส่วนประกอบที่แตกต่างกันและแทนที่รูปแบบการจัดเก็บของมันบ่อยครั้ง; สิ่งนี้ทำให้พวกเขาสามารถแนะนำคุณสมบัติใหม่ (เช่นการสนับสนุนที่ดีขึ้นสำหรับการรวมกับระบบควบคุมการแก้ไขตามแนวคิดต่าง ๆ ) และปรับปรุงประสิทธิภาพ ทีมบาซ่าร์พิจารณาการติดตามไดเรกทอรีและเปลี่ยนชื่อรองรับฟังก์ชั่นชั้นหนึ่ง ในขณะที่ตัวระบุการตรวจทานแก้ไขรหัสที่ไม่ซ้ำกันทั่วโลกนั้นมีให้สำหรับการแก้ไขทั้งหมด, การ revnos ต้นไม้ท้องถิ่น (หมายเลขการแก้ไขมาตรฐาน, คล้ายกับที่ใช้โดย svn หรือ SCM แบบอื่น ๆ ที่มากกว่า) ใช้แทนแฮชเนื้อหาเพื่อระบุการแก้ไข Bazaar มีการรองรับ "การจ่ายเงินเบา" ซึ่งจะถูกเก็บไว้ในเซิร์ฟเวอร์ระยะไกลแทนการคัดลอกลงในระบบท้องถิ่นและถูกเรียกโดยอัตโนมัติผ่านเครือข่ายเมื่อจำเป็น; ในปัจจุบันสิ่งนี้มีความพิเศษในหมู่ DSCM

ทั้งสองมีรูปแบบการรวม SVN บางส่วน อย่างไรก็ตาม bzr-svn นั้นมีความสามารถมากกว่า git-svn อย่างมากเนื่องจากการปรับปรุงรูปแบบแบ็กเอนด์ที่นำมาใช้เพื่อจุดประสงค์นั้น [อัพเดต, ณ ปี 2014: ผลิตภัณฑ์เชิงพาณิชย์ของบุคคลที่สาม SubGit ให้อินเตอร์เฟซแบบสองทิศทางระหว่าง SVN และ Git ซึ่งเทียบเคียงได้กับ bzr-svn และมีความเที่ยงตรงมากกว่า; ฉันขอแนะนำให้ใช้มากกว่า git-svn เมื่อข้อ จำกัด ด้านงบประมาณและใบอนุญาตอนุญาต]

ฉันไม่ได้ใช้ Mercurial อย่างกว้างขวางและดังนั้นจึงไม่สามารถให้ความเห็นในรายละเอียดได้ - ยกเว้นที่จะต้องทราบว่าเช่น Git มีการแฮชเนื้อหาเพื่อแก้ไข เช่นเดียวกับ Git มันไม่ถือว่าไดเรกทอรีเป็นวัตถุชั้นหนึ่ง (และไม่สามารถจัดเก็บไดเรกทอรีว่าง) อย่างไรก็ตามมันเร็วกว่า DSCM อื่น ๆ ยกเว้น Git และมีการรวม IDE ที่ดีกว่า (โดยเฉพาะกับ Eclipse) กว่าคู่แข่งใด ๆ ด้วยคุณสมบัติด้านประสิทธิภาพ (ซึ่งล่าช้าเพียงเล็กน้อยด้านหลังของ Git) และการสนับสนุนข้ามแพลตฟอร์มและ IDE ที่เหนือกว่า Mercurial อาจจะน่าสนใจสำหรับทีมที่มีสมาชิกจำนวน 32 คนที่มุ่งเน้น win32-centric หรือ IDE-bound

ข้อกังวลอย่างหนึ่งในการย้ายจาก SVN คือส่วนหน้า GUI ของ SVN และการรวม IDE นั้นมีความเป็นผู้ใหญ่มากกว่า SCM แบบกระจาย นอกจากนี้หากคุณใช้งานสคริปต์อัตโนมัติแบบ precommit จำนวนมากกับ SVN (เช่นการทดสอบหน่วยที่จะผ่านก่อนที่การกระทำสามารถดำเนินการต่อได้) คุณอาจต้องการใช้เครื่องมือที่คล้ายกับPQMสำหรับการรวมคำขออัตโนมัติไปยังสาขาที่แบ่งปันของคุณ

SVK เป็น DSCM ซึ่งใช้การโค่นล้มเป็นที่เก็บข้อมูลสำรองและมีการรวมที่ดีกับเครื่องมือ SVN เป็นศูนย์กลาง อย่างไรก็ตามมันมีประสิทธิภาพที่แย่ลงและมีความสามารถในการขยายขนาดได้มากกว่า DSCM หลักอื่น ๆ (แม้แต่ Darcs) และควรหลีกเลี่ยงสำหรับโครงการที่มีแนวโน้มที่จะเติบโตอย่างมากในแง่ของความยาวของประวัติหรือจำนวนไฟล์

[เกี่ยวกับผู้แต่ง: ฉันใช้ Git และ Perforce สำหรับงานและ Bazaar สำหรับโครงการส่วนตัวของฉันและเป็นห้องสมุดฝังตัว ส่วนอื่น ๆ ขององค์กรนายจ้างของฉันใช้ Mercurial อย่างหนัก ก่อนหน้านี้ฉันสร้างระบบอัตโนมัติรอบ SVN ขึ้นมามากมาย ก่อนหน้านั้นฉันมีประสบการณ์กับ GNU Arch, BitKeeper, CVS และอื่น ๆ ในตอนแรก Git ค่อนข้างจะวางตัว - มันให้ความรู้สึกเหมือน GNU Arch ซึ่งเป็นสภาพแวดล้อมที่มีแนวคิดหนักเมื่อเทียบกับชุดเครื่องมือที่สร้างขึ้นเพื่อให้สอดคล้องกับตัวเลือกเวิร์กโฟลว์ของผู้ใช้ - แต่ฉันรู้สึกสบายใจ มัน].

สตีฟ Streeting ของโครงการยักษ์ 3 มิติเพียง (2009/09/28) การเผยแพร่รายการบล็อกเกี่ยวกับหัวข้อนี้ที่เขาทำดีและแม้กระทั่งมือเปรียบเทียบ Git, Mercurial และบาซาร์

ในที่สุดเขาก็พบจุดแข็งและจุดอ่อนกับทั้งสามและไม่มีผู้ชนะที่ชัดเจน ด้านบวกเขาให้ตารางที่ยอดเยี่ยมที่จะช่วยคุณตัดสินใจว่าจะไปกับอะไร

มันสั้นอ่านและฉันขอแนะนำอย่างยิ่ง

คนที่นี่เห็นว่าอะไรเป็นจุดแข็งและจุดอ่อนของ Git, Mercurial และ Bazaar

ในความคิดของฉันความแข็งแกร่งของGitคือการออกแบบที่สะอาดและคุณสมบัติที่หลากหลาย ฉันคิดว่าการสนับสนุนที่ดีที่สุดสำหรับที่เก็บหลายสาขาและการจัดการเวิร์กโฟลว์ที่มีสาขาหนัก มันเร็วมากและมีพื้นที่เก็บข้อมูลขนาดเล็ก

มีคุณสมบัติบางอย่างที่มีประโยชน์ แต่ใช้ความพยายามที่จะใช้พวกเขา สิ่งเหล่านี้รวมถึงอาเรย์ระยะกลางที่มองเห็นได้ (ดัชนี) ระหว่างพื้นที่ทำงานและฐานข้อมูลพื้นที่เก็บข้อมูลซึ่งช่วยให้การผสานความละเอียดที่ดีขึ้นในกรณีที่ซับซ้อนยิ่งขึ้นการคอมมิตแบบเพิ่มหน่วยและการคอมไพล์ด้วยต้นไม้สกปรก การตรวจจับการเปลี่ยนชื่อและการคัดลอกโดยใช้วิธีแก้ปัญหาแบบคล้ายคลึงกันมากกว่าการติดตามโดยใช้รหัสไฟล์บางชนิดซึ่งทำงานได้ดีและอนุญาตให้มีการตำหนิ (คำอธิบายประกอบ) ซึ่งสามารถติดตามการเคลื่อนไหวของรหัสในไฟล์ต่างๆและไม่เพียงเปลี่ยนชื่อขายส่ง

ข้อเสียอย่างหนึ่งของมันคือการที่ MS Windows รองรับการล้าหลังและไม่เต็ม ข้อเสียที่รับรู้อีกอย่างหนึ่งก็คือมันไม่ได้บันทึกไว้อย่างดีเช่น Mercurial และมีผู้ใช้น้อยกว่าคู่แข่ง แต่มันเปลี่ยนแปลง

ในความเห็นของฉันความแข็งแกร่งของMercurial นั้นอยู่ในประสิทธิภาพที่ดีและมีพื้นที่เก็บข้อมูลขนาดเล็กในการรองรับ MS Windows ที่ดี

หลักของฉันคือความจริงที่ว่าสาขาท้องถิ่น (หลายสาขาในพื้นที่เก็บข้อมูลเดียว) ยังคงเป็นพลเมืองชั้นสองและในทางที่แปลกและซับซ้อนก็มีการติดแท็ก วิธีการจัดการกับการเปลี่ยนชื่อไฟล์ก็ทำได้ดีกว่า (แต่การย้ายครั้งนี้มีการเปลี่ยนแปลง) Mercurial ไม่สนับสนุนการรวมปลาหมึกยักษ์ (กับพ่อแม่มากกว่าสองคน)

จากสิ่งที่ฉันเคยได้ยินและอ่านข้อดีหลักของบาซ่าร์คือการสนับสนุนเวิร์กโฟลว์แบบรวมศูนย์ (ซึ่งก็เป็นข้อเสียด้วยแนวคิดแบบรวมศูนย์ที่มองเห็นไม่ควร) การติดตามการเปลี่ยนชื่อไฟล์และไดเรกทอรี

ข้อเสียเปรียบหลักคือประสิทธิภาพและขนาดของที่เก็บสำหรับที่เก็บขนาดใหญ่ที่มีประวัติไม่เชิงเส้นยาว (ประสิทธิภาพที่ปรับปรุงอย่างน้อยสำหรับที่เก็บไม่ใหญ่เกินไป) ข้อเท็จจริงที่ว่ากระบวนทัศน์เริ่มต้นคือหนึ่งฟาร์มต่อหนึ่งที่เก็บ (คุณสามารถตั้งค่า และแนวคิดแบบรวมศูนย์ (แต่นั่นก็มาจากสิ่งที่ฉันเคยได้ยินการเปลี่ยนแปลง)

Git เขียนใน C, เชลล์สคริปต์และ Perl, และสามารถเขียนได้ Mercurial เขียนด้วย C (core, for performance) และ Python และจัดทำ API สำหรับส่วนขยาย Bazaar เขียนด้วย Python และให้บริการ API สำหรับส่วนขยาย

ในการพิจารณาแต่ละข้อด้วยกันและต่อต้านระบบควบคุมเวอร์ชันเช่น SVN และ Perforce ควรพิจารณาประเด็นใดบ้าง

ระบบควบคุมเวอร์ชันเช่น Subversion (SVN), Perforce หรือ ClearCase เป็นระบบควบคุมเวอร์ชันรวมศูนย์ Git, Mercurial, Bazaar (และ Darcs, Monotone และ BitKeeper) เป็นระบบควบคุมเวอร์ชันที่แจกจ่าย ระบบควบคุมเวอร์ชันแบบกระจายช่วยให้มีเวิร์กโฟลว์ที่หลากหลายมากขึ้น อนุญาตให้ใช้ "เผยแพร่เมื่อพร้อม" พวกเขามีการสนับสนุนที่ดีกว่าสำหรับการแยกและการรวมและสำหรับเวิร์กโฟลว์ที่มีสาขามาก คุณไม่จำเป็นต้องเชื่อใจผู้คนด้วยการให้สิทธิ์ในการเข้าถึงเพื่อรับการสนับสนุนจากพวกเขาในวิธีที่ง่าย

ในการวางแผนการโอนย้ายจาก SVN ไปยังหนึ่งในระบบควบคุมเวอร์ชันกระจายเหล่านี้คุณจะพิจารณาปัจจัยใดบ้าง

ปัจจัยหนึ่งที่คุณอาจต้องการพิจารณาคือการสนับสนุนสำหรับการใช้ SVN แบบไม่ใช้งาน Git มี git-svn, Bazaar มี bzr-svn และ Mercurial มีส่วนขยาย hgsubversion

ข้อจำกัดความรับผิดชอบ:ฉันเป็นผู้ใช้ Git และผู้มีเวลาน้อยและดู (และมีส่วนร่วมใน) รายชื่อผู้รับจดหมาย git ฉันรู้ Mercurial และ Bazaar จากเอกสารประกอบการอภิปรายต่างๆเกี่ยวกับ IRC และรายชื่อผู้รับจดหมายและโพสต์บล็อกและบทความเปรียบเทียบระบบควบคุมเวอร์ชันต่าง ๆ (บางส่วนอยู่ในหน้าGitComparisonบน Git Wiki)

InfoQ มีการเปรียบเทียบที่ดี

Mercurial และ Bazaar มีลักษณะคล้ายกันมากบนพื้นผิว พวกเขาทั้งสองให้การควบคุมเวอร์ชันกระจายขั้นพื้นฐานเช่นเดียวกับการกระทำแบบออฟไลน์และการรวมสาขาหลายแห่งทั้งสองเขียนในหลามและช้ากว่า git มีความแตกต่างมากมายเมื่อคุณเจาะลึกรหัส แต่สำหรับงานประจำวันของคุณพวกเขาก็มีประสิทธิภาพเหมือนกันแม้ว่า Mercurial ดูเหมือนจะมีแรงผลักดันเพิ่มขึ้นเล็กน้อย

Git ดีไม่ได้สำหรับมือใหม่ มันเร็วกว่าทั้ง Mercurial และ Bazaar และถูกเขียนขึ้นเพื่อจัดการเคอร์เนล Linux มันเร็วที่สุดในสามตัวและยังทรงพลังที่สุดในสามตัวด้วยอัตรากำไรขั้นต้น บันทึกของ Git และเครื่องมือการจัดการกระทำไม่ตรงกัน อย่างไรก็ตามมันก็ซับซ้อนและอันตรายที่สุดในการใช้งาน มันง่ายมากที่จะสูญเสียการกระทำหรือทำลายที่เก็บโดยเฉพาะอย่างยิ่งถ้าคุณไม่เข้าใจการทำงานภายในของคอมไพล์

ลองดูที่การเปรียบเทียบที่ทำเมื่อเร็ว ๆ นี้โดยนักพัฒนาหลาม: http://wiki.python.org/moin/DvcsComparison พวกเขาเลือก Mercurial ด้วยเหตุผลสำคัญสามประการ:

ตัวเลือกที่จะไปกับ Mercurial นั้นถูกสร้างขึ้นด้วยเหตุผลสำคัญสามประการ:

• จากการสำรวจขนาดเล็กผู้พัฒนา Python สนใจที่จะใช้ Mercurial มากกว่าใน Bazaar หรือ Git
• Mercurial เขียนด้วย Python ซึ่งสอดคล้องกับแนวโน้มของ python-dev ที่จะ 'กิน dogfood ของตัวเอง'
• Mercurial เร็วกว่า bzr อย่างมาก (ช้ากว่า git แม้ว่าจะแตกต่างกันเล็กน้อย)
• Mercurial ง่ายต่อการเรียนรู้สำหรับผู้ใช้ SVN มากกว่า Bazaar

(จากhttp://www.python.org/dev/peps/pep-0374/ )

Sun ทำการประเมินgit , MercurialและBazaarเป็นผู้สมัครเพื่อแทนที่ Sun Teamware VCS สำหรับฐานรหัส Solaris ฉันพบว่ามันน่าสนใจมาก

สิ่งที่ขาดหายไปที่สำคัญมากในตลาดสดคือซีพี คุณไม่สามารถมีหลายไฟล์ร่วมกันประวัติศาสตร์เช่นเดียวกับที่คุณมีใน SVN, ดูตัวอย่างที่นี่และที่นี่ หากคุณไม่ได้วางแผนที่จะใช้ cp, bzr เป็นการแทนที่ (และใช้งานง่ายมาก) สำหรับ svn

ฉันใช้ Bazaar อยู่พักหนึ่งซึ่งฉันชอบมาก แต่ก็เป็นเพียงโครงการขนาดเล็กและแม้กระทั่งตอนนี้มันก็ค่อนข้างช้า ง่ายต่อการเรียนรู้ แต่ไม่เร็วมาก มันเป็นแพลตฟอร์ม x มาก

ปัจจุบันฉันใช้ Git ซึ่งฉันชอบมากตั้งแต่รุ่น 1.6 ทำให้มันคล้ายกับ VCS อื่น ๆ ในแง่ของคำสั่งที่จะใช้

ฉันคิดว่าความแตกต่างที่สำคัญสำหรับประสบการณ์การใช้ DVCS ของฉันคือ:

1. Git มีชุมชนที่มีชีวิตชีวาที่สุดและเป็นเรื่องปกติที่จะเห็นบทความเกี่ยวกับ Git
2. GitHubโขดหินจริงๆ Launchpad.net ก็โอเค แต่ไม่มีอะไรที่เหมือนกับความพอใจของ Github
3. จำนวนเครื่องมือเวิร์กโฟลว์สำหรับ Git นั้นยอดเยี่ยมมาก มันรวมกันทุกที่ มีบางอย่างสำหรับ Bzr แต่ไม่มากหรือบำรุงรักษาเกือบดี

โดยสรุป Bzr นั้นยอดเยี่ยมเมื่อฉันตัดฟันของฉันบน DVCS แต่ตอนนี้ฉันมีความสุขมากกับ Git และ Github

นี่เป็นคำถามที่ยิ่งใหญ่ที่ขึ้นอยู่กับบริบทที่ต้องใช้เวลามากในการพิมพ์ลงในกล่องข้อความเล็ก ๆ เหล่านี้ นอกจากนี้ทั้งสามสิ่งนี้ปรากฏคล้ายกันอย่างมากเมื่อใช้กับสิ่งปกติที่โปรแกรมเมอร์ส่วนใหญ่ทำดังนั้นแม้แต่การเข้าใจความแตกต่างก็จำเป็นต้องมีความรู้ที่ค่อนข้างลึกลับ

คุณอาจได้รับคำตอบที่ดีกว่านี้หากคุณสามารถวิเคราะห์เครื่องมือเหล่านี้ได้จนถึงจุดที่คุณมีคำถามเพิ่มเติม

Bazaar นั้นง่ายต่อการเรียนรู้มากกว่า git Git ได้รับการสนับสนุนที่ดีใน github.com

ฉันคิดว่าคุณควรลองใช้ทั้งคู่และตัดสินใจว่าแบบไหนที่เหมาะกับคุณที่สุด

คนที่นี่เห็นว่าอะไรเป็นจุดแข็งและจุดอ่อนของ Git, Mercurial และ Bazaar

นี่เป็นคำถามที่เปิดกว้างมากติดกับ flamebait

Git เร็วที่สุด แต่ทั้งสามนั้นเร็วพอ บาซ่าร์มีความยืดหยุ่นมากที่สุด (มีการสนับสนุนการอ่าน - เขียนแบบโปร่งใสสำหรับที่เก็บ SVN) และใส่ใจกับประสบการณ์ของผู้ใช้เป็นอย่างมาก Mercurial อยู่ตรงกลาง

ทั้งสามระบบมีแฟนบอยจำนวนมาก ฉันเป็นแฟนบอยของ Bazaar

ในการพิจารณาแต่ละข้อด้วยกันและต่อต้านระบบควบคุมเวอร์ชันเช่น SVN และ Perforce ควรพิจารณาประเด็นใดบ้าง

อดีตเป็นระบบกระจาย หลังเป็นระบบรวมศูนย์ นอกจากนี้อย่างเลี่ยงไม่พ้นเป็นกรรมสิทธิ์ในขณะที่คนอื่น ๆ ทั้งหมดได้ฟรีในขณะที่คำพูด

การรวมศูนย์กับการกระจายอำนาจเป็นทางเลือกที่สำคัญยิ่งกว่าระบบใด ๆ ที่คุณกล่าวถึงในหมวดหมู่

ในการวางแผนการโอนย้ายจาก SVN ไปยังหนึ่งในระบบควบคุมเวอร์ชันกระจายเหล่านี้คุณจะพิจารณาปัจจัยใดบ้าง

ขั้นแรกให้ขาดการทดแทนที่ดีสำหรับ TortoiseSVN แม้ว่า Bazaar กำลังทำงานกับเต่าของพวกเขาแต่มันยังไม่มีในเดือนกันยายน 2008

จากนั้นการฝึกอบรมบุคคลสำคัญเกี่ยวกับวิธีการใช้ระบบการกระจายอำนาจจะส่งผลกระทบต่อการทำงานของพวกเขา

ในที่สุดการรวมเข้ากับส่วนที่เหลือของระบบเช่นตัวติดตามปัญหาระบบสร้างตอนกลางคืนระบบทดสอบอัตโนมัติ ฯลฯ

ปัญหาที่สำคัญของคุณก็คือปัญหาเหล่านี้คือSCM แบบกระจายและดังนั้นจึงจำเป็นต้องเปลี่ยนความคิดของผู้ใช้เล็กน้อย เมื่อผู้คนคุ้นเคยกับแนวคิดนี้รายละเอียดทางเทคนิคและรูปแบบการใช้งานจะตกหล่น แต่อย่าประมาทอุปสรรค์ครั้งแรกโดยเฉพาะในองค์กร โปรดจำไว้ว่าปัญหาทั้งหมดเป็นปัญหาของคน

ddaa.myopenid.com พูดถึงมันผ่าน แต่ฉันคิดว่ามันควรค่าแก่การพูดถึงอีกครั้ง: Bazaar สามารถอ่านและเขียนไปยังที่เก็บข้อมูล SVN ระยะไกลได้ นั่นหมายความว่าคุณสามารถใช้ Bazaar ในพื้นที่เป็นหลักฐานพิสูจน์แนวคิดในขณะที่คนอื่น ๆ ในทีมยังคงใช้การโค่นล้ม

แก้ไข: สวยมากทุกเครื่องมือในขณะนี้มีบางส่วนวิธีการมีปฏิสัมพันธ์กับ SVN แต่ตอนนี้ผมมีประสบการณ์ส่วนตัวที่git svnทำงานมากดี ฉันใช้มันมาหลายเดือนโดยมีอาการสะอึกน้อยที่สุด

มีวิดีโอที่ดีโดย Linus Torvalds บนคอมไพล์ เขาเป็นผู้สร้าง Git ดังนั้นนี่คือสิ่งที่เขาโปรโมต แต่ในวิดีโอเขาอธิบายว่า SCM แบบกระจายคืออะไรและทำไมพวกเขาถึงดีกว่าแบบรวมศูนย์ มีการเปรียบเทียบ git (Mercurial ถือว่าโอเค) และ cvs / svn / perforce นอกจากนี้ยังมีคำถามจากผู้ชมเกี่ยวกับการย้ายถิ่นไปยัง SCM แบบกระจาย

ฉันพบว่าวัสดุนี้ให้ความกระจ่างและฉันถูกขายให้กับ SCM แบบกระจาย แต่ความพยายามของฉันก็คือไลนัส เหตุผลก็คือ bitbucket.org ฉันคิดว่ามันดีขึ้น (ใจกว้างมากขึ้น) แล้วค่อย gitHub

ฉันต้องพูดคำเตือนที่นี่: Linus มีสไตล์ที่ก้าวร้าวมากฉันคิดว่าเขาอยากจะตลก แต่ฉันไม่ได้หัวเราะ นอกจากนั้นวิดีโอยังดีถ้าคุณยังใหม่กับ SCM แบบกระจายและคิดถึงการย้ายจาก SVN

http://www.youtube.com/watch?v=4XpnKHJAok8

ระบบควบคุมเวอร์ชันแจกจ่าย (DVCSs) แก้ปัญหาที่แตกต่างจาก VCS ส่วนกลาง การเปรียบเทียบมันเปรียบได้กับการเปรียบเทียบค้อนกับไขควง

ส่วนกลาง VCSระบบได้รับการออกแบบด้วยความตั้งใจที่ว่ามีหนึ่งแหล่งที่มาของทรูที่มีความสุขและดังนั้นจึงดี นักพัฒนาซอฟต์แวร์ทั้งหมดทำงาน (ชำระเงิน) จากแหล่งข้อมูลนั้นแล้วเพิ่ม (กระทำ) การเปลี่ยนแปลงของพวกเขาซึ่งกลายเป็นพรในทำนองเดียวกัน ข้อแตกต่างที่แท้จริงระหว่าง CVS, การโค่นล้ม, ClearCase, Perforce, VisualSourceSafe และ CVCSes อื่น ๆ ทั้งหมดอยู่ในเวิร์กโฟลว์ประสิทธิภาพและการรวมที่แต่ละผลิตภัณฑ์มี

ระบบVCS แบบกระจายได้รับการออกแบบโดยมีจุดประสงค์เพื่อให้ที่เก็บหนึ่งแห่งนั้นดีเท่ากับที่อื่น ๆ และที่ผสานจากที่เก็บหนึ่งไปยังอีกที่หนึ่งเป็นเพียงการสื่อสารรูปแบบอื่น ค่าความหมายใด ๆ ที่เป็นที่เก็บควรเชื่อถือได้ถูกกำหนดจากภายนอกโดยกระบวนการไม่ใช่ซอฟต์แวร์เอง

ตัวเลือกที่แท้จริงระหว่างการใช้ประเภทหนึ่งหรืออีกประเภทหนึ่งคือแบบองค์กร - หากโครงการหรือองค์กรของคุณต้องการการควบคุมจากส่วนกลางแบบ DVCS นั้นไม่ใช่แบบเริ่มต้น หากนักพัฒนาของคุณคาดว่าจะทำงานได้ทั่วประเทศ / โลกโดยไม่ต้องเชื่อมต่อบรอดแบนด์ที่ปลอดภัยไปยังที่เก็บข้อมูลส่วนกลาง DVCS น่าจะเป็นความรอดของคุณ หากคุณต้องการทั้งสองอย่างคุณจะต้อง fsck