เทคนิคการโค่นล้มขั้นสูงฉันหายไปอะไร

10

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

ตัวอย่างเช่น

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

version-control

— Derek Adair
แหล่งที่มา

3

คุณอาจต้องการพิจารณาใช้ hg สำหรับสาขาในพื้นที่ของคุณ (คุณสามารถใช้กับ svn ได้ดีตรวจสอบสิ่งนี้ )

— OneOfOne

ฮา! คุณไม่มีความเมตตา

— DexterW

3

"การโค่นล้มขั้นสูง" เสียงเหมือน oxymoron ใช้ Git หรือ Mercurial หากอยู่ในพื้นที่เท่านั้น

— Macneil

7

ในการพูดถึงตัวอย่างของคุณคุณมีความเป็นไปได้สามประการที่จะทำเช่นนั้น:

คุณสามารถส่งไฟล์เดียวได้ หากคุณใช้ IDE เพื่อเข้าถึงพื้นที่เก็บข้อมูลก็จะมีมุมมองที่เป็นไปได้มากที่สุดในการเลือกหรือยกเลิกการเลือกไฟล์เดียวก่อนที่จะกระทำ บนบรรทัดรับคำสั่งคุณพิมพ์svn commit file1 path1/file2 path2เพื่อคอมมิต file1, path1 / file2 และทุกการเปลี่ยนแปลงภายใต้ path2
คุณสามารถทำสำเนาการทำงานที่แตกต่างกัน คุณทำงานกับคุณสมบัติขนาดใหญ่ของคุณในสำเนาการทำงานมาตรฐานและรับข้อมูลเกี่ยวกับข้อผิดพลาดเร่งด่วน คุณสามารถชำระเงินที่เก็บของคุณไปยังไดเรกทอรีอื่นและแก้ไขข้อบกพร่องในสำเนาการทำงานที่สองนี้ คุณสามารถตรวจสอบไดเรกทอรีย่อยที่มีองค์ประกอบที่เกิดข้อผิดพลาด หลังจากแก้ไขข้อผิดพลาดคุณสามารถส่งในสำเนาการทำงานที่สองของคุณโดยไม่ต้องทำงานของคุณในคุณสมบัติใหญ่ แก้ไข: วิธีการที่อธิบายไว้ในคำตอบของ Anna Lear
คุณสร้างสาขาสำหรับงานในฟีเจอร์ของคุณ เพื่อให้คุณใช้คำสั่งคัดลอก ถ้าคุณใช้มาตรฐานรูปแบบสำหรับพื้นที่เก็บข้อมูลของคุณ (ไดเรกทอรีกับ projectname และไดเรกทอรีที่มีชื่อลำต้น, แท็กและสาขาลำต้นมีโครงการ) คุณสามารถใช้ SVN svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-Xสำเนาคำสั่งดังต่อไปนี้เช่นการสร้างสาขา: ตอนนี้คุณสามารถสลับสำเนาการทำงานของคุณไปยังสถานที่ใหม่: svn switch svn://hostname/projectname/branches/branch-for-feature-Xสวิทช์ หากคุณสลับในโหมดแก้ไขข้อผิดพลาดที่คุณยอมรับการเปลี่ยนแปลงจริงของคุณให้สลับสำเนาการทำงานของคุณกลับไปที่ลำต้นแก้ไขข้อผิดพลาดและการกระทำและสลับสำเนาการทำงานกลับไปที่ฟีเจอร์สาขาของคุณ หากคุณพร้อมที่จะพัฒนาฟีเจอร์นี้คุณสามารถรวมมันกลับไปที่ลำต้น

สำหรับกรณีธรรมดาที่อธิบายไว้คุณมักจะใช้ # 1 (ฉันใช้บ่อยที่สุด) บางครั้ง # 2 การทำงานกับสาขา (กรณี # 3) นั้นซับซ้อนกว่า ( อ่านเพิ่มเติม ) แต่อนุญาตให้ใช้กลอุบายเพิ่มเติมได้ แต่สาขาตรงกับคำอธิบายย่อยของคุณ

นอกเหนือจากตัวอย่างของคุณฉันไม่สามารถพูดอะไรได้มาก มีหลายสิ่งเกี่ยวกับการโค่นล้ม แต่ฉันไม่รู้ว่าคุณใช้ไปแล้วและสิ่งที่คุณต้องการสำหรับโครงการของคุณ สำหรับการเรียนรู้เพิ่มเติมเกี่ยวกับ SVN SVN-Book เป็นแหล่งข้อมูลที่ยอดเยี่ยม: http://svnbook.red-bean.com/

— Mnementh
แหล่งที่มา

3

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

— สตีเฟ่นซี. เหล็ก

7

คุณสามารถตรวจสอบรหัสลงใน sandbox ที่แตกต่างกันแทนที่จะเพียงแค่คัดลอกหนึ่งชุดและทำการเปลี่ยนแปลงทั้งหมดที่นั่น

ดังนั้นคุณสามารถมีโครงสร้างโฟลเดอร์ที่เป็นดังนี้:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

เป็นต้น

ทั้งหมดของผู้ที่จะได้รับการตรวจสอบออกจากสถานที่เดียวกันใน SVN http://mysvnrepo/trunkของคุณเช่น

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

— อดัมเลียร์
แหล่งที่มา

4

คุณเคยดูSubversion Branchesบ้างไหม?

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

อีกวิธีคือการมีสาขาสำหรับรีลีสหนึ่ง ๆ เพื่อหลีกเลี่ยงการทำงานอื่น ๆ โดยไม่ได้ตั้งใจบนลำต้นทำให้เกิดปัญหา คุณสามารถแก้ไขข้อผิดพลาด 'Release Branch' ได้ตามต้องการจากนั้นจึงพับโปรแกรมแก้ไขเหล่านั้นกลับไปที่ trunk เมื่อพร้อม

นักพัฒนาของคุณสามารถมีสำเนาการทำงานหลายรายการที่ตรวจสอบ - ลำต้นและสาขาใด ๆ - หรือสามารถสลับระหว่างลำต้นและสาขาเฉพาะด้วยsvn switchคำสั่ง

ฉันไม่แนะนำให้มีสำเนาการทำงาน 'sandbox' จำนวนมากที่คุณเก็บเงินแยกต่างหากเนื่องจาก (a) สิ่งนี้ห้ามการทำงานร่วมกันกับผู้อื่นและ (b) มันจะง่ายเกินไปที่จะตั้งใจกระทำโดยไม่ได้ตั้งใจ

— JBRWilkinson
แหล่งที่มา

3

ขนาดสำเนาการทำงานปัจจุบันของฉันคือ 10GB พร้อมไฟล์มากกว่า 50,000 ไฟล์ ฉันสามารถมีหลายชุดสำหรับสาขาที่แตกต่างกัน แต่ใช้เวลาสักครู่เพื่อสร้างสำเนาใหม่!

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

— ซาเวียร์โนเดต
แหล่งที่มา