การใช้ SVN ไม่ดี - Mercurial เป็นคำตอบหรือไม่

13

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

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

นี่เป็นวิธีการที่ดีหรือไม่? โปรดทราบว่าทีมมีความยืดหยุ่นสูงและจะไปพร้อมกับสิ่งที่จะปรับปรุงคุณภาพการทำงานของเราและทำให้วิธีการที่เราทำสิ่งต่าง ๆ ง่ายขึ้น - CIO ถามฉันเมื่อฉันพูดถึงวิธีที่เราไม่ได้ใช้ SVN เพื่อศักยภาพ " มีบางอย่างที่ดีกว่าที่เราสามารถใช้ได้? " ดังนั้นเขาจึงขึ้นเครื่องด้วยเช่นกัน

version-control svn mercurial

— เวย์นโมลินา
แหล่งที่มา

13

HgInit - มันเริ่มต้นด้วยการโค่นล้มการศึกษาใหม่ซึ่งฉันคิดว่าคุณจะพบว่ามีประโยชน์

— yannis

20

คุณไม่กลัวว่าพวกเขาจะใช้ Hg ได้ไม่ดีเช่นกัน?

— Oded

6

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

— maple_shaft

2

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

— maple_shaft

4

@maple_shaft I will probably not take DVCS very seriously until I end up on a large development teamหรือจนกว่าคุณจะจบลงด้วยการกระจายทีม เราเป็นทีมเล็ก ๆ (5 คน) ทำงานจาก 3 สถานที่ (และบางครั้ง 5 เมื่อเราไม่รู้สึกอยากลุกออกจากเตียง) และการเปลี่ยนจาก svn เป็น hg เป็นการต้อนรับหนึ่ง ...

— yannis

15

ใช่.

หากคุณแทนที่ "SVN" ด้วย "Perforce" ใน OP ของคุณคุณจะได้รับสถานการณ์ที่ฉันพบว่าตัวเองเมื่อฉันเริ่มงานปัจจุบันของฉันแม้กระทั่งการคัดลอกการเปลี่ยนแปลงด้วยตนเอง สองปีที่เราอยู่ใน Mercurial และทุกคนตกลงกันว่ามันเป็นการเปลี่ยนแปลงครั้งใหญ่

เรามีความสามารถในการแยกสาขาและรวมต่อการสนับสนุนกรณีซึ่งเป็นประโยชน์อย่างไม่น่าเชื่อสำหรับ QA และความสามารถในการสร้างสาขาและที่เก็บแบบโยนทิ้งจำนวนเท่าใดก็ตามที่เราเห็นว่าเหมาะสมซึ่งเราสามารถสร้างและตรวจสอบในเซิร์ฟเวอร์ CI ของเรา กับสภาพแวดล้อมการทดสอบคลาวด์และตรวจสอบการทำงาน นี่เป็นประโยชน์อย่างมากในแง่ของความอุ่นใจว่าเมื่อเราทำการปรับใช้สดเราเกือบ 100% มั่นใจว่ามันจะทำงาน (ปัญหา sans environment / DB ซึ่งเห็นได้ชัดว่าอยู่นอกขอบเขตของ VCS)

โดยพื้นฐานแล้วสิ่งที่เราได้จากการเปลี่ยนมาใช้ Mercurial คือการหายใจในอวกาศ เราไม่ต้องกังวลเกี่ยวกับค่าใช้จ่ายของสาขาหรือช่วงการรวมที่น่ากลัวที่ใช้ในการติดตามอย่างหลีกเลี่ยงไม่ได้ทุกอย่างง่ายขึ้นมาก นอกจากนี้เรายังใช้ FogBugz ค่อนข้างหนักดังนั้นการผูกเข้ากับ Kiln (mercurial โฮสต์ของพวกเขา) มีประโยชน์จริง ๆ

ความคิดเห็นเกี่ยวกับไซต์hginitก็มีให้เห็นเช่นกันเนื่องจากเป็นเค้าโครงสำหรับเวิร์กโฟลว์การควบคุมเวอร์ชันที่ใช้งานได้จริง

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

ฉันไม่เห็นด้วยกับความคิดเห็นเกี่ยวกับขนาดของทีมและการกระจายทีมที่เกี่ยวข้องกับว่าจะใช้ DCVS หรือไม่ จริงๆแล้วมันเกี่ยวกับการแจกแจง CODE หากคุณมีวัฏจักรการพัฒนาหลายอย่างเกิดขึ้นพร้อมกันไม่ว่าจะเป็นกรณีการสนับสนุนในระบบมรดกหรือคุณสมบัติมากมายหรือแม้แต่ระบบใหม่ (ซึ่งตามเสียงของคุณ) คุณจะได้รับประโยชน์จากการใช้ DVCS

— เอ็ดเจมส์
แหล่งที่มา

3

-1 หากนักพัฒนาซอฟต์แวร์มีปัญหาดังกล่าวกับการโค่นล้มมันไม่น่าเป็นไปได้อย่างยิ่งที่พวกเขาจะ "ได้รับ" ระบบที่ซับซ้อนมากขึ้น คำตอบที่ถูกต้องคือตามความเห็นในคำถามที่กล่าวว่าการศึกษาใหม่ของวิธีการโค่นล้ม (และ VCS โดยทั่วไป) ทำงาน ...

— Izkata

1

@EdWoodcock ฉันคิดว่าสิ่งที่คุณสังเกตอาจเป็นเพราะทีมของคุณต้องเริ่มต้นด้วย "กระดานชนวนสะอาด" การเปลี่ยนแปลงที่ครอบคลุมของ VCS เป็น Mercurial หมายความว่าทุกคนต้องเริ่มต้นใหม่และไม่สามารถพึ่งพานิสัยที่ไม่ดีที่พวกเขาใช้ใน SVN ได้อีกต่อไป หลายครั้งมันง่ายที่จะเอาชนะนิสัยที่ไม่ดี "เริ่มต้น" ในบริบทอื่น (ในกรณีนี้ mercurial)

— อันเจโล

2

@EdWoodcock: Perforce อาจมีการแตกสาขาที่เลวร้ายที่สุดของ VCS ใด ๆ ที่ยังใช้งานอยู่ การแตกแขนงใน SVN นั้นง่ายกว่ามาก

— kevin cline

1

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

— อันเจโล

1

@ChrisS คำอุปมานั้นใช้ได้กับ VCS มาตรฐานมากขึ้นซึ่งมีค่าใช้จ่ายในการแยกสาขา นอกจากนี้ยังมีการพูดคุยเกี่ยวกับการแยกสาขากระทำและผสานอีกครั้งซึ่ง <i> คุณทำทุกครั้งที่คุณโคลน </i> ใน DVCS นอกจากนี้ฉันเพิ่งอธิบายว่าทำไมวิธีการนี้จึงใช้งานได้จริงสำหรับเรา การดันทุรังเกี่ยวกับวิธีการนั้นค่อนข้างโง่

— Ed James

21

เครื่องมือที่แตกต่างกันอาจจะไม่แก้ปัญหาของคุณฉันว่าคุณควรอ่านบทความนี้ฉันพบว่ามีประโยชน์มากที่สุด:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

ฉันคิดว่าประเด็นหลักของบทความนั้นสรุปไว้ที่นี่ แต่โปรดอ่าน:

ในที่สุด: ไม่เกี่ยวกับเครื่องมือจริงๆ

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

— น้ำแข็งสีดำ
แหล่งที่มา

6

+1 มันไม่เกี่ยวกับเครื่องมือจริงๆ SVN มีความสามารถอย่างสมบูรณ์แบบตามที่จำเป็น

— อันเจโล

1

นี่คือทั้งหมดที่เกี่ยวกับคนไม่ใช่เครื่องมือ ฉันได้เห็นโครงการที่ได้รับการจัดการเป็นอย่างดียังคงใช้ระบบรุ่นต่อเนื่องสำหรับการควบคุมเวอร์ชันเช่นเดียวกับโครงการที่น่ากลัวที่ใช้ GIT หรือ Mercurial ..

— Alexander Galkin

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

— Chris S

3

ในขณะที่ฉันยอมรับว่ามันเป็นวิธีที่คุณใช้เครื่องมือของคุณที่นับเป็นกรณีที่เครื่องมือต่าง ๆ นำคุณไปในทิศทางที่แตกต่างกัน เครื่องมืออย่าง Mercurial นำคุณสู่เส้นทางแห่งความเรียบง่ายและความยืดหยุ่น Git นำคุณสู่เส้นทางแห่งความซับซ้อน แต่มีความยืดหยุ่นสูงการโค่นล้มทำให้บางสิ่งง่ายกว่าสิ่งอื่นดังนั้นคุณจึงหลีกเลี่ยงสิ่งที่ยากและยุ่งเหยิงในขณะที่ Visual Sourcesafe นำคุณสู่เส้นทางที่ยืดหยุ่นและหงุดหงิด * 8 ')

— ทำเครื่องหมายบูธ

10

ไม่เทคโนโลยีไม่ค่อยแก้ปัญหาแบบนี้

Mercurial นั้นซับซ้อนกว่าการโค่นล้ม (ใช่การแตกแขนงและการรวมนั้นดีกว่าและอาจจะง่ายกว่า แต่โมเดลของการโค่นล้มนั้นง่ายกว่า Mercurial มาก) หากคุณใช้การโค่นล้มในลักษณะที่เป็นสมองคุณอาจท้ายด้วยการใช้ Mercurial:

a) เพียงพอหรือดีกว่า
b) ไม่เพียงพอ แต่ดีกว่าการใช้การโค่นล้มในปัจจุบันของคุณ
c) ไม่เพียงพอเหมือนตอนนี้
d) ยิ่งกว่าตอนนี้

c) และ d) ฟังดูเหมือนผลลัพธ์ที่เป็นไปได้มากที่สุด เขียนเหตุผลที่คุณคิดว่าจะจบลงด้วยก) หรือข)

— อเล็กซ์
แหล่งที่มา

5

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

— Brian Knoblauch
แหล่งที่มา

3

ไม่เครื่องมือไม่ได้เปลี่ยนวิธีการ

หากคุณไม่ใช้การโค่นล้มเป็น SCMคุณไม่สามารถ ใช้ Mercurial ได้เช่นกัน (และอาจเกิดขึ้นได้)

— ขี้เกียจแบดเจอร์
แหล่งที่มา

2

SVN สามารถทำสิ่งที่คุณต้องการและไม่จำเป็นต้องเปลี่ยนม้ากลางคันสำหรับการจ่ายเงินที่น่าสงสัย

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

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

นำ "โค้ช" มาจัดเตรียมเวิร์คช็อปให้กับทีม สิ่งนี้จะต้องเป็นบุคคลภายนอก (แดกดันมันมักจะง่ายกว่าสำหรับหลาย ๆ ทีมที่จะไว้วางใจคนนอกได้มากกว่าที่จะไว้วางใจใครบางคนในทีม) ต้องเป็นคนที่รู้สิ่งภายในของเธอและสามารถสอนทักษะเหล่านี้ให้กับผู้คนในทุกระดับของความเข้าใจและวางแผนในการปฏิบัติเพื่อนำ VCS (*) ออกไปสู่กระบวนการทำงานของทีมได้อย่างมีประสิทธิภาพ
เริ่มต้นโครงการ "skunk-works" เพื่อทดสอบไดรฟ์และตรวจสอบ VCS ใหม่ในโครงการขนาดเล็ก เลือกนักพัฒนา "อัลฟ่า" สองสามคนที่ยินดีลองสิ่งใหม่ ๆ และไม่รังเกียจที่จะทดลองใช้ไม่สำเร็จ เมื่องานเสนียดสามารถแสดงให้เห็นถึงการปรับปรุงอย่างไม่น่าเชื่อคอนกรีตในเวิร์กโฟลว์แล้วคุณสามารถพยายามที่จะแผ่ออกไปยังส่วนที่เหลือของทีมและคุณมี evangelists สองสามเพื่อช่วยให้คุณทำ

(*) โดย "new VCS" ฉันไม่ได้แปลว่า mercurial หรือ git มันอาจเป็น SVN (ทำได้ถูกต้อง)

— แองเจโล
แหล่งที่มา