เหตุใดการแตกแขนงและการรวมเข้าด้วยกันใน Mercurial จึงง่ายกว่าการโค่นล้ม?

การจัดการการผสานหลายรายการเข้ากับสาขาใน Subversion หรือ CVS เป็นเพียงหนึ่งในสิ่งเหล่านั้นที่ต้องมีประสบการณ์ การติดตามสาขาและการรวมใน Mercurial นั้นง่ายกว่ามาก (และอาจเป็นระบบกระจายอื่น ๆ ) แต่ฉันไม่รู้ว่าทำไม มีใครรู้บ้างไหม?

คำถามของฉันเกิดจากข้อเท็จจริงที่ว่าด้วย Mercurial คุณสามารถใช้วิธีปฏิบัติในการทำงานที่คล้ายกับที่เก็บส่วนกลางของ Subversions / CVSs และทุกอย่างจะทำงานได้ดี คุณสามารถทำการผสานหลายรายการในสาขาเดียวกันและคุณไม่ต้องใช้เศษกระดาษที่ไม่มีที่สิ้นสุดพร้อมหมายเลขคอมมิตและชื่อแท็ก

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

ต้องมีความแตกต่างพื้นฐานในวิธีการทำงานทั้งหมด

ในการโค่นล้ม (และ CVS) ที่เก็บเป็นอันดับแรกและสำคัญที่สุด ใน git และ mercurial ไม่มีแนวคิดของพื้นที่เก็บข้อมูลในลักษณะเดียวกัน การเปลี่ยนแปลงที่นี่เป็นธีมหลัก

+1

ความยุ่งยากใน CVS / SVN มาจากการที่ระบบเหล่านี้ไม่ จดจำความเป็นพ่อแม่ของการเปลี่ยนแปลง ใน Git และ Mercurial ไม่เพียง แต่สามารถมีลูกหลายคนได้ แต่ยังสามารถมีพ่อแม่หลายคนได้อีกด้วย!

ซึ่งสามารถสังเกตได้ง่ายโดยใช้เครื่องมือกราฟิกอย่างใดอย่างหนึ่งgitkหรือhg view. ในตัวอย่างต่อไปนี้สาขา # 2 ถูกแยกจาก # 1 ที่คอมมิต A และตั้งแต่นั้นมารวมกันหนึ่งครั้ง (ที่ M รวมกับคอมมิต B):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

หมายเหตุวิธี A และ B มีลูกสองคนในขณะที่ M มีสองพ่อแม่ ความสัมพันธ์เหล่านี้ถูกบันทึกไว้ในที่เก็บ สมมติว่าผู้ดูแลสาขา # 2 ตอนนี้ต้องการผสานการเปลี่ยนแปลงล่าสุดจาก branch # 1 พวกเขาสามารถออกคำสั่งเช่น:

$ git merge branch-1

และเครื่องมือจะรู้โดยอัตโนมัติว่าฐานคือ B - เนื่องจากถูกบันทึกในการกระทำ M ซึ่งเป็นบรรพบุรุษของส่วนปลายของ # 2 - และต้องรวมสิ่งที่เกิดขึ้นระหว่าง B และ C CVS จะไม่บันทึกข้อมูลนี้ และ SVN ก่อนหน้าเวอร์ชัน 1.5 ในระบบเหล่านี้กราฟจะมีลักษณะดังนี้:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

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

เลวยังดำเนินการผสานสองจะกลายเป็นฝันร้าย: หนึ่งจะต้องคิดออกว่าฐานผสานเป็นช่วงเวลาของการผสานแรก (และหนึ่งมีที่จะทราบ ว่าได้มีการผสานในสถานที่แรก!) แล้วในปัจจุบันว่า ข้อมูลไปยังเครื่องมือเพื่อที่จะไม่พยายามเล่น A..B ซ้ำบน M ทั้งหมดนี้เป็นเรื่องยากพอสมควรเมื่อทำงานร่วมกันอย่างใกล้ชิด แต่เป็นไปไม่ได้เลยในสภาพแวดล้อมแบบกระจาย

ปัญหา (ที่เกี่ยวข้อง) คือไม่มีวิธีตอบคำถาม: "X มี B หรือไม่" โดยที่ B คือการแก้ไขข้อบกพร่องที่สำคัญ ดังนั้นทำไมไม่เพียงแค่บันทึกข้อมูลนั้นในการกระทำเนื่องจากเป็นที่รู้กันในเวลารวม!

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

เนื่องจาก Subversion (อย่างน้อยเวอร์ชัน 1.4 และต่ำกว่า) ไม่ได้ติดตามสิ่งที่รวมเข้าด้วยกัน สำหรับการโค่นล้มการรวมจะเหมือนกับการกระทำใด ๆ ในขณะที่อยู่ในการควบคุมเวอร์ชันอื่น ๆ เช่น Git สิ่งที่ถูกผสานจะถูกจดจำ

ไม่ถูกแตะต้องโดยคำตอบใด ๆ ที่ให้ไว้แล้ว Hg นำเสนอความสามารถในการผสานที่เหนือกว่าเนื่องจากใช้ข้อมูลเพิ่มเติมเมื่อรวมการเปลี่ยนแปลง ( hginit.com ):

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

แน่นอนว่าการจดจำสิ่งที่รวมครั้งสุดท้าย (ประเด็นที่ตอบโดยคำตอบส่วนใหญ่ที่ให้ไว้ที่นี่) ก็เป็นชัยชนะที่ยิ่งใหญ่เช่นกัน

อย่างไรก็ตามการปรับปรุงทั้งสองเป็นเรื่องที่น่าสงสัยเนื่องจากการโค่นล้ม 1.5+ เก็บข้อมูลการผสานเพิ่มเติมในรูปแบบของคุณสมบัติการโค่นล้ม: ข้อมูลที่มีอยู่ไม่มีเหตุผลที่ชัดเจนว่าทำไมการรวมการโค่นล้มไม่สามารถใช้การผสานได้สำเร็จเท่ากับ Hg หรือ Git ฉันไม่รู้ว่ามันทำได้หรือเปล่า แต่ดูเหมือนว่านักพัฒนาที่ถูกโค่นล้มกำลังพยายามแก้ไขปัญหานี้

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

ในการโค่นล้ม (และ CVS) ที่เก็บเป็นอันดับแรกและสำคัญที่สุด ใน git และ mercurial ไม่มีแนวคิดของพื้นที่เก็บข้อมูลในลักษณะเดียวกัน การเปลี่ยนแปลงที่นี่เป็นธีมหลัก

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

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

ถ้า Mercurial สามารถทำให้การกำหนดค่าของการผสานง่ายขึ้นฉันสามารถพูดได้ว่าจะทำให้การรวมง่ายขึ้น 100% จากนั้น Subversion