SVN ล้าสมัยหรือไม่ [ปิด]

9

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

ปิดให้บริการใน9 ปีที่ผ่านมา

เป็นเพียงไม่กี่ปีนับตั้งแต่ฉันย้ายจาก Visual Source Safe เป็น SVN และ SVN สำหรับฉันยังคงชนิด "ว้าว! ฉันสามารถทำสิ่งต่าง ๆ มากมาย! SVN เจ๋งมาก!"

แต่หลายคนรอบตัวฉันพูดว่า "SVN จริงเหรอ? Meh ... "

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

ดังนั้น ... SVN นั้นเลวจริงเหรอ? ฉันจะพลาดโอกาสอันยิ่งใหญ่โดยติดกับมันหรือไม่?

git svn

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

นี่อาจเป็นการอ่านที่น่าสนใจ: stackoverflow.com/questions/161541/svn-vs-git

— fouronnes

คุณเป็นนักพัฒนาอิสระหรือไม่

— TeaDrinkingGeek

6

ฉันมักจะใช้ GIT ตอนนี้ฉันต้องใช้ SVN ในที่ทำงาน .... ... ... ... ... ... ... ... RAGE

— Ivo Wetzel

@TeaDrinkingGeek: OP บอกว่า "ฉันควรย้ายทีมของฉัน ... " ดังนั้นฉันจึงคาดเดาว่ามีมากกว่า OP ที่เกี่ยวข้อง (เว้นแต่คุณจะนับทีมหนึ่งทีม - แต่โดยทั่วไปจะไม่เรียกว่า "ทีมของฉัน" )

— FrustratedWithFormsDesigner

เพื่อนขอโทษด้วยตาเบลอเล็กน้อยหลังจาก 12 ชั่วโมงบนแล็ปท็อป :)

— TeaDrinkingGeek

8

มันขึ้นอยู่กับการใช้งานทั้งหมด

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

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

— William Pietri
แหล่งที่มา

8

อย่ากวาดไปในกระแสของ hypes คุณมีสิ่งที่ใช้งานได้ใช้ต่อไปจนกว่าจะมีความต้องการทางธุรกิจที่จะได้พบกับสิ่งอื่นที่ดีกว่า (ไม่ระบบการควบคุมแหล่งใหม่ที่สดใสหรือภาษาการเขียนโปรแกรมทุก ๆ สองสามเดือนทุกครั้งที่มีอะไร "ใหม่ เพื่อตอบสนองความต้องการทางธุรกิจของคุณดีกว่าที่คุณใช้อยู่ตอนนี้)

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

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

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

ฉันจะลงคะแนนให้คุณล้านครั้งถ้าทำได้

— HLGEM

5

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

— Karl Bielefeldt
แหล่งที่มา

5

ฉันชอบที่จะทำการตัดสินใจส่วนใหญ่จากความไม่รู้ คุณแนะนำให้เขาใช้เวลาหนึ่งเดือนในการลองคอมไพล์ นั่นเป็นงานจริง เขาควรทำอย่างนั้นถ้ามีเหตุผลบางอย่างที่เชื่อว่ามันจะทำให้สถานการณ์ของเขาดีขึ้นมาก มิฉะนั้นอาจมีอย่างอื่นที่เขาควรใช้เดือนของการทดลอง เช่น redis หรือ mongo หรือ rails หรือ node.js หรือ BDD สิ่งใหม่ ๆ ที่เท่าเทียมกัน

— William Pietri

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

— Kyralessa

3

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

— Mason Wheeler
แหล่งที่มา

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

— greyfade

1

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

— ทางเลือก

@ Mathepic: คุณสามารถเปลี่ยนชื่อได้หากคุณต้องการ แต่แนวคิดพื้นฐานของการถ่ายโอนข้อมูลระหว่างสำเนาการทำงานในท้องถิ่นและที่เก็บอย่างเป็นทางการมีอยู่ในระบบควบคุมแหล่งใด ๆ

— Mason Wheeler

1

ไม่มันไม่ ไม่มีการดำเนินการดังกล่าวใน DVCS

— ทางเลือก

3

ใช่มี - จุดของ repo ส่วนกลางที่จะผลักดันรุ่น 'master' เป็นกรณีการใช้งานที่ถูกต้องไม่ว่าจะเป็นการสำรองข้อมูล, build-server, การจัดการปล่อยหรือเพียงวิธีการประสานที่ดีขึ้นระหว่างทีม

— gbjbaanb

-2

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

— JB King
แหล่งที่มา

3

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

— HLGEM