SVN ทำอะไรได้ดีกว่า Git [ปิด]

293

ไม่มีคำถามว่าส่วนใหญ่ของการอภิปรายมากกว่าเครื่องมือโปรแกรมเมอร์กลั่นทั้งทางเลือกส่วนบุคคล (โดยผู้ใช้) หรือเน้นการออกแบบ , ที่ , การเพิ่มประสิทธิภาพการออกแบบตามโดยเฉพาะอย่างยิ่งการใช้กรณี (โดยสร้างเครื่องมือ) โปรแกรมแก้ไขข้อความอาจเป็นตัวอย่างที่โดดเด่นที่สุด - coder ที่ทำงานบน Windows ในที่ทำงานและรหัสในHaskellบน Mac ที่บ้านค่าข้ามแพลตฟอร์มและการรวมคอมไพเลอร์และเลือกEmacsผ่านTextMateฯลฯ

เป็นเรื่องธรรมดาที่เทคโนโลยีที่เพิ่งนำมาใช้ใหม่นั้นมีความเหนือกว่าตัวเลือกที่ยังหลงเหลืออยู่

ในความเป็นจริงแล้วกรณีนี้เกิดขึ้นกับระบบควบคุมเวอร์ชัน (VCS) โดยเฉพาะอย่างยิ่งVCS แบบรวมศูนย์ ( CVSและSVN ) กับVCS ( GitและMercurial ) แบบกระจาย ?

ฉันใช้ SVN เป็นเวลาประมาณห้าปีและปัจจุบัน SVN ใช้ในที่ทำงานของฉัน น้อยกว่าสามปีก่อนฉันเปลี่ยนมาใช้ Git (และ GitHub) สำหรับโครงการส่วนตัวทั้งหมดของฉัน

ฉันสามารถคิดถึงข้อดีหลายประการของ Git ในการโค่นล้ม (และนามธรรมส่วนใหญ่จะเป็นข้อได้เปรียบของการกระจายไปยัง VCS ส่วนกลาง) แต่ฉันไม่สามารถคิดถึงตัวอย่างที่ตรงกันข้ามได้ - งานบางอย่าง (ที่เกี่ยวข้องและเกิดขึ้นในโปรแกรมเมอร์ตามปกติ เวิร์กโฟลว์) การโค่นล้มทำได้ดีกว่า Git

เพียงข้อสรุปที่ผมได้มาจากนี้ก็คือว่าผมไม่ได้มีข้อมูลใด ๆ - ไม่ว่า Git จะดีกว่า ฯลฯ

ฉันเดาว่าตัวอย่างเคาน์เตอร์มีอยู่ดังนั้นคำถามนี้

tools  git  version-control 
— doug
แหล่งที่มา
3
@ jokoon: มีประสิทธิภาพในแง่ของอะไร ไม่เร็วอย่างแน่นอนเพราะแม้แต่อีเธอร์เน็ตที่รวดเร็วก็ยังทำงานช้าเมื่อเทียบกับการใช้งานในท้องถิ่น
— maaartinus
4
— detly
4
ฉันคิดเสมอว่า Git นั้นได้รับความนิยมอย่างสูง มันเป็นแฟชั่นและโปรแกรมเมอร์ไม่อนุญาตให้แฟชั่น - แม้จะตรงข้ามกับความคิดนี้ เช่นเดียวกับคนอื่น ๆ ในโลกนี้ทุกคนต้องการของเล่นใหม่ที่เป็นประกาย(Git) Git อาจดี - หรือดีสำหรับบางคน - แต่มันไม่เคยดีไปกว่า SVN เมื่อคิดอย่างเป็นกลาง
— ซื้อ 777
3
ฉันคิดว่า SVN ยังใช้งานได้ดีส่วนโค้งการเรียนรู้ก็ดี GIT
— Cheung
5
คำถามนี้ถูกพักไว้เมื่อเร็ว ๆ นี้โดยยึดหลักความคิดเห็นเป็นหลัก การจำแนกประเภทนั้นผิด โปรดทราบว่าคำถามนั้นเปิดมาเป็นเวลานาน มีคำถามมากมายเกี่ยวกับคุณธรรมของ DVCS และคำถามนั้นไม่ได้ถามว่ามันดีกว่า (ความเห็น) แต่มันทำอะไรได้ดีกว่า ความแตกต่างไม่ใช่ความเห็น แต่ไม่ว่าจะเป็นผลิตภัณฑ์โดยรวมหรือไม่นั่นเป็นเรื่องยุ่งยาก (แต่ไม่ใช่ประเด็นของคำถามนี้)
— Eamon Nerbonne

คำตอบ:

207

การโค่นล้มเป็นพื้นที่เก็บข้อมูลกลาง

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

การโค่นล้มเป็นภูมิปัญญาดั้งเดิม

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

การโค่นล้มไม่ทางเดียวและไม่มีอะไรอื่น

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

ข้อดีอื่น ๆ คือ:

  • SVN สนับสนุนไดเรกทอรีว่างเปล่า
  • SVN มีการรองรับ Windows ที่ดีกว่า
  • SVN สามารถตรวจสอบ / โคลนต้นไม้ย่อย
  • SVN รองรับการควบคุมการเข้าถึงแบบเอกสิทธิ์เฉพาะบุคคลsvn lockซึ่งมีประโยชน์สำหรับไฟล์ที่ยากต่อการผสาน
  • SVN รองรับไฟล์ไบนารีและไฟล์ขนาดใหญ่ได้ง่ายขึ้น (และไม่จำเป็นต้องคัดลอกเวอร์ชั่นเก่าทุกที่)
  • การเพิ่มขั้นตอนที่เกี่ยวข้องกับการกระทำมากน้อยเนื่องจากมีไม่ดึงใด ๆ / ผลักดันและการเปลี่ยนแปลงในท้องถิ่นของคุณมักจะ rebased svn updateโดยปริยายใน
— treecoder
แหล่งที่มา
55
"การโค่นล้มทำได้ในทางเดียว" - ฉันก็คิดเช่นนั้นจนกระทั่งฉันเริ่มงานปัจจุบันของฉัน ในงานปัจจุบันของฉันเจ้านายของฉันที่อ้างว่าไม่มีปัญหาความน่าเชื่อถือตั้งค่าเซิร์ฟเวอร์ให้ต้องล็อค ไม่มีการรวมเกิดขึ้นในระบบของเรา ไฟล์ถูกล็อคในที่เก็บและไม่มีใครสามารถเขียนไฟล์เหล่านั้นได้โดยไม่ต้องล็อค การควบคุมจากบนลงล่างสำหรับผู้ที่ต้องการรัฐธรรมนูญเป็นสิ่งที่ svn ทำได้ดีกว่า git
— Dan Ray
14
ข้อดีอย่างหนึ่งของที่เก็บส่วนกลางคือความสะดวกในการสำรองข้อมูล หากรหัสเช็คอินทั้งหมดอยู่ในที่เดียวและที่เดียวมีการสำรองนอกไซต์คุณจะไม่สูญเสียทุกสิ่งหากสำนักงานของคุณถูกไฟไหม้ ด้วย DVCS เว้นแต่คุณจะสำรองข้อมูลนอกสถานที่ของเครื่องของนักพัฒนาซอฟต์แวร์คุณจะสูญเสียทุกสิ่งที่ไม่ได้ถูกผลักไปยังเซิร์ฟเวอร์ที่สำรองข้อมูลนอกสถานที่
— พอลทอมบลิน
94
เหตุใดจึงไม่สามารถใช้คอมไพล์ในลักษณะรวมศูนย์ได้ เพียงแค่มีที่เก็บส่วนกลางหนึ่งแห่งและ devs ของคุณสามารถโคลนและดึงและดันเหมือนที่พวกเขาเช็คเอาต์และอัปเดตและกระทำ
— David Thornley
29
@PaulTomblin - ขึ้นอยู่กับเวิร์กโฟลว์ Git สามารถให้การสำรองข้อมูลที่ดีกว่า ตัวอย่างเช่นเราใช้ repos GitHub ส่วนตัวและฉันมักจะผลักดันรหัสของฉันไปที่สาขาคุณสมบัติ หากเพื่อนร่วมงานของฉันทำgit fetch originพวกเขาแต่ละคนมีการสำรองข้อมูลรหัสของฉันพร้อมกับการสำรองข้อมูลใด ๆ ที่ Github ให้ (เราตัดกิ่งที่รวมสาขาอย่างสม่ำเสมอทั้งในประเทศและบน Github)
— นาธานลอง
52
คุณดูเหมือนจะบอกว่าศูนย์กลางมีความปลอดภัยมากขึ้นสำหรับ บริษัท ขนาดใหญ่หรืองานราชการ นี้เป็นเพียงไม่เป็นความจริง. หากคุณมีสำเนาของรหัสในคอมพิวเตอร์ของคุณคุณมีสำเนาของรหัส ไม่สำคัญว่ามาจากเซิร์ฟเวอร์กลางหรือระบบไฟล์กลางที่เก็บที่เก็บ DVCS
— John Fisher
131

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

และประโยชน์เล็ก ๆ น้อย ๆ : การโค่นล้มสามารถติดตามไดเรกทอรีว่างเปล่า Git ติดตามเนื้อหาไฟล์ดังนั้นไดเรกทอรีที่ไม่มีไฟล์จะไม่ปรากฏขึ้น

— johannes
แหล่งที่มา
11
การทำงานกับทรีย่อยคือ IMHO สิ่งเดียวที่ SVN มีเหนือ GIT จุดที่ว่างไดเรกทอรีที่ดี แต่ไม่จำเป็นเช่นกัน (และสามารถแก้ไขได้) หากซับทอเลชั่น git และทรีย่อยของ git มีความสับสนน้อยลงจะไม่มีอะไรทำให้คนจำนวนมากกลับมาจากการโยกย้ายมายัง GIT ข้อดีอื่น ๆบางคนกล่าวถึงต้มลงไปที่ความคิด (นักพัฒนา) เช่นถ้าคุณต้องการจากบนลงล่างก็ไม่เป็นไร ฉันจะไม่ทำงานให้คุณ
— จนถึง
3
เป็นเรื่องตลกที่ว่าสิ่งเหล่านี้เป็นเพียงสิ่งเดียวที่สามารถโต้แย้งในความโปรดปรานของ SVN (และการควบคุมเวอร์ชันรวมศูนย์อื่น ๆ )
— dukeofgaming
1
ทำไมมันตลก? - ระบบที่ใหม่กว่าเรียนรู้จากระบบเก่า มีประโยชน์กับ RCS มากกว่า git: ไฟล์ประวัติสามารถแก้ไขได้อย่างง่ายดายด้วยมือและคุณสามารถมีสาขาต่อไฟล์ แต่เกี่ยวข้องกับการ eolution ว่าตรงจะหายไป ...
— โยฮันเน
3
ฉันได้ยินเรื่อง บริษัท เกมที่ใช้ SVN บน GIT ด้วยเหตุผลนี้ - เมื่อคุณพูดถึงที่เก็บขนาด GB หลาย ๆ อันมันสำคัญมาก!
— James
18
ในฐานะของ git รุ่น 1.8.0 ตอนนี้คุณสามารถใช้git subtreeคำสั่งเพื่อทำสิ่งนี้ให้สำเร็จ ข้อได้เปรียบในการโค่นล้มครั้งล่าสุดกัดฝุ่น :) รายละเอียดที่นี่: github.com/gitster/git/blob/…หมายเหตุ: แม้ว่านี่จะเป็นลิงค์ไปยังโครงการ gitub แต่ตอนนี้ git-subtree เป็นส่วนหนึ่งของการกระจายแกนหลัก
— Carl
51

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

นี่ไม่ได้หมายความว่าเราจะไม่ย้ายการพัฒนาทั้งหมดไปที่ Mercurial

— Peter Mortensen
แหล่งที่มา
25
การที่ grok ง่ายกว่านั้นเป็นข้อได้เปรียบที่สำคัญเนื่องจากทำให้มีแนวโน้มที่จะถูกใช้มากกว่า SVN นั้นดีกว่าไม่มีการควบคุมเวอร์ชันและถ้ามีคนหัวแข็งเกี่ยวกับวิธีการแบบเก่าบางที SVN อาจเป็นตัวเลือกที่ดีที่สุดสำหรับพวกเขา
— jhocking
12
@ jhocking: ฉันไม่ชอบ SVN แต่ถ้ามีคนบอกฉันว่า "ฉันไม่ชอบสิ่ง DVCS ใหม่ดังนั้นฉันจะอยู่กับ CVS" ดังนั้นฉันจะแนะนำอย่างแน่นอน : มันเป็นถนนที่ง่ายต่อการอย่างน้อย บางส่วนมีสติ VCS ;-)
— Joachim Sauer
4
@ jhocking วิธีการใหม่ ๆ ไม่ใช่สิ่งที่ดีที่สุดสำหรับทุกสถานการณ์ มันทำให้นึกถึงเรื่องราวเก่าแก่เกี่ยวกับ NASA ที่ใช้เงินหลายล้านดอลลาร์ในการพัฒนาปากกาที่สามารถเขียนเป็น 0 กรัม นักบินอวกาศในทางกลับกันทำด้วยดินสอ บางครั้งวิธีการแบบเก่าจะดีกว่าตอนนี้รับออกกฎหมายของฉัน!
— maple_shaft
25
@maple_shaft และบางครั้งก็ไม่ใช่ snopes.com/business/genius/spacepen.asp
— Peter Taylor
3
grokked ง่าย ๆ เป็นอัตนัยและขึ้นอยู่กับว่าคุณพยายามปรับความรู้ใหม่ให้เข้ากับสิ่งที่คุณอาจรู้อยู่แล้ว นอกจากนี้ยังสร้างความแตกต่างอย่างมากว่าแหล่งเรียนรู้ของคุณคืออะไร ถ้าคุณไปหน้าคนโชคดี หากคุณได้รับการสอนจากครูที่ดีที่คอยสอนอยู่แล้ว ฉันพบว่าคอมไพล์มีเหตุผลอย่างมากหลังจากดูวิดีโอที่ดีหลายรายการบน YouTube หากคุณเข้าใจจากใครบางคนที่ได้กลั่นมันลงไปสู่แกนกลางง่ายๆแล้วทุกอย่างก็จะเข้าใจง่ายขึ้น
— WarrenT
32
  • ที่เก็บ SVN สามารถจัดการได้จากมุมมองของผู้จัดการและผู้ดูแลระบบ ( ACL + วิธีการตรวจสอบความถูกต้อง + hotcopy + mirror + dumps)
  • SVN * - ตะของ่ายต่อการนำไปใช้และสนับสนุน
  • svn:external มีพลังและความยืดหยุ่นมากกว่า submodules
  • แผนผังที่เก็บแบบอิงระบบไฟล์ใช้งานง่ายกว่าที่เก็บเสาหินที่มีการแยกแบบโลจิคัลเท่านั้น
  • SVN มีเครื่องมือไคลเอนต์ที่แตกต่างกันมากขึ้น
  • SVN มีส่วนหน้าเว็บที่ใช้งานได้ของบุคคลที่สามซึ่งดีกว่า Git มาก
  • SVN ไม่ทำลายสมองของคุณ
— Lazy Badger
แหล่งที่มา
23
ไม่ทำลายสมองของคุณ? ต้องการสอนวิธีผสานสาขากับความขัดแย้งใน SVN ได้อย่างง่ายดายหรือไม่
— WarrenT
4
เครื่องมือ / ส่วนหน้า "ดีกว่า" นั่นเป็นเป้าหมายที่เคลื่อนที่ เครื่องมือปรับปรุงทั้งสองด้าน พวกเราไม่มีใครรู้ว่าเครื่องมืออะไรที่จะสามารถใช้ได้หลายปีจากนี้ การประเมินนั้นเมื่อ 10 เดือนที่แล้วอาจเปลี่ยนแปลงได้ง่ายเมื่อเวลาผ่านไปและอาจค้างอยู่ในขณะนี้ ฉันต้องการเห็นคำตอบที่สำคัญ
— WarrenT
6
ต้นไม้ขัดแย้งกันไหม? ตรวจสอบ ใช่หรือไม่สำหรับตัวเลือกทั้งหมด? ไม่ Svn ถูกออกแบบมาเพื่อทำให้โกรธ ล้างคำสั่งคัดลอกการทำงานหรือไม่ ไม่ได้ Revert ไม่สามารถล้างไฟล์ที่ไม่มีเวอร์ชันได้
— วอร์เรน P
1
การลบทุกอย่างและตรวจสอบอีกครั้งจะเป็นการทำความสะอาดไฟล์ที่ไม่มีเวอร์ชัน
— jgmjgm
ฉันรักความคิดสุดท้ายของคุณ Git ทำให้สมองของฉันแตกสลาย: '(
— ลุ
24

ฉันเขียนสิ่งนี้เป็นความคิดเห็นในคำตอบของคนอื่น แต่ฉันคิดว่ามันสมควรที่จะเป็นคำตอบในตัวของมันเอง

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

SVN ควบคุมการจัดการจากบนลงล่างได้ดีกว่า Git ในการโยกย้าย skunkworks ของฉันไปที่ Git (ขอการอภัยมากกว่าการขออนุญาต) ฉันกลัวผู้จัดการของฉันหลายครั้งด้วยความคิดว่าไม่มีเซิร์ฟเวอร์ควบคุมกลางที่บังคับใช้กับซอฟต์แวร์ใดที่เราเป็นทาสทั้งหมด

— Dan Ray
แหล่งที่มา
ศูนย์กลางเป็นเรื่องของตำนานไม่จริง ไม่มีใครสามารถหยุดฉันจากการเปลี่ยนแปลงอะไรก็ได้ ด้วย cvcs พวกเขาสามารถหยุดฉันจากการเปลี่ยนแปลงบางสิ่งบางอย่างจากส่วนกลาง สิ่งเดียวกันใน dvcs คำว่ากระทำใน cvcs conflates กระทำและผลักดัน
— วอร์เรน P
@ JonathanHenson: นั่นไม่ใช่เหตุผลเดียวที่ Torvalds เกลียด SVN SVN อาจถูกรวมศูนย์และอาจเป็น CVS ที่ดีขึ้น แต่นั่นก็แทบจะไม่ทำให้มันเป็นซอฟต์แวร์ที่ดี Torvalds เกลียด CVS / SVN ไม่ใช่เพราะพวกเขารวมศูนย์ แต่เพราะเขาคิดว่าพวกเขาเป็นซอฟต์แวร์ที่ไม่ดีอย่างน่าสงสาร ไม่ว่าเขาจะถูกหรือไม่ก็ขึ้นอยู่กับคุณที่จะตัดสินใจ แต่ได้เห็นความสำเร็จอันยิ่งใหญ่ของทั้งลินุกซ์ (และ Android) - ทำงานบนอุปกรณ์หลายพันล้านรายการ - และ Git - ซึ่งค่อนข้างจะพาโลกมาจากพายุ - ฉัน ลองคิดดูสองครั้งก่อนที่จะไม่เห็นด้วยกับเขา การบรรยาย Torvalds ที่ Google มอบให้เมื่อ Git เมื่อหลายปีก่อนเป็นเรื่องที่น่าอัศจรรย์
— Cedric Martin
ฮ่า ๆ. ผู้จัดการของคุณถูกต้องน่าหวาดกลัวไม่มีระบบสำรองข้อมูลที่เหมาะสม เพียงแค่พูดว่า "แต่มันเป็น DVCS มันจะมีใครบางคนมีสำเนา" ไม่ได้บิน - ฉันรู้ว่าเมื่อฉันเห็นคอมไพล์ที่ใช้ในสถานที่สุดท้ายของฉันพวกเขาไม่มีสำเนาของ repos บางตัว โปรดทราบว่าการล็อกอาจดีสำหรับบางสถานการณ์และการคอมไพล์ล้มเหลวในเรื่องนี้ - เว้นแต่คุณจะมีเครื่องมือผสานที่วิเศษสำหรับรูปภาพหรือไฟล์ไบนารีอื่น ๆ git ใช้งานได้กับไฟล์ข้อความเท่านั้น
— gbjbaanb
22

เหตุผลของฉัน:

  • ครบกำหนด - ทั้งเซิร์ฟเวอร์และเครื่องมือ (เช่น TortoiseSVN)
  • ความเรียบง่าย - ขั้นตอนที่เกี่ยวข้องน้อยกว่าการกระทำคือการกระทำ DVCS เช่น Git และ Mercurial เกี่ยวข้องกับการคอมมิชชันจากนั้นกด
  • การจัดการแบบไบนารี - SVN สามารถจัดการไฟล์ประมวลผลและรูปภาพได้ดีกว่า Git / Hg มีประโยชน์อย่างยิ่งกับโครงการ. NET เนื่องจากฉันต้องการตรวจสอบเครื่องมือที่เกี่ยวข้องกับการสร้างลงในการควบคุมแหล่งที่มา
  • การกำหนดหมายเลข - SVN มีรูปแบบการกำหนดหมายเลขที่สามารถอ่านได้โดยใช้เพียงหลัก - ง่ายต่อการติดตามหมายเลขการแก้ไข Git และ Hg ทำสิ่งนี้แตกต่างกันมาก
— Grant Palin
แหล่งที่มา
1
"ยอมรับโครงร่างการกำหนดหมายเลข" เป็นไปได้เฉพาะถ้าคุณมีกางเกงที่ยอมรับ มิฉะนั้นตัวไหนจะได้หมายเลขที่สำคัญ?
1
+1 numbring ใน svn หมายเลขนี้ไม่ซ้ำกัน มีเครื่องมือในการใช้หมายเลขนี้เป็นส่วนหนึ่งของ app-versionnumber xx.yy.zz.12882 โดยที่ 12882 เป็นหมายเลขเวอร์ชัน svn หากมีปัญหาเกี่ยวกับการผลิตคุณสามารถขอหมายเลขเวอร์ชันและคุณมี svn-revision ที่ถูกต้องซึ่งซอฟต์แวร์ถูกสร้างขึ้นด้วย
— k3b
22

ฉันขอขอบคุณที่คุณกำลังมองหาข้อมูลที่ดี แต่คำถามแบบนี้ขอเชิญชวน "ฉันคิดว่า Git นั้นชนะมากและ svn teh suxorz!" คำตอบ

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

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

ประเด็นที่ฉันพยายามทำก็คือถ้าคุณเป็นทีมเล็ก ๆ ที่ทำงานในโครงการขนาดกลางถึงเล็กและคุณคุ้นเคยกับ SVN แล้วให้ใช้มัน มันดีกว่า CVS หรือ (ตัวสั่น) SourceSafeและฉันใช้เวลาไม่เกินห้านาทีในการตั้งค่าที่เก็บ บางครั้ง Git ก็สามารถ overkill ได้

— maple_shaft
แหล่งที่มา
3
จริงๆ? จากนั้นผมขอแนะนำให้คุณมีลักษณะที่ฟอสซิล
— Spencer Rathbun
7
อย่าส่งเสียงเตือนเมื่อมีความขัดแย้งน้อยที่สุด หัวข้อสำคัญมักจะเป็นประเด็นที่ถกเถียงกันมากที่สุด ดังนั้น "คำถามประเภทนี้" จึงมีความสำคัญและความเป็นไปได้ของการตอบสนองนอกขอบเขตไม่น่าจะเป็นไปได้ที่จะไม่โพสต์ ฉันถือว่าผู้ใช้ในเว็บไซต์นี้เป็นผู้ใหญ่ ยิ่งไปกว่านั้นวิธีที่ Q ของฉันถูกใช้เป็นคำพูดคือถ้าไม่เป็นกลางจากนั้นให้เลื่อนไปที่การโค่นล้มคน - คำตอบที่ตอบสนองต่อคำถามของฉันจะต้องท่องข้อได้เปรียบของการโค่นล้มมากกว่า Git ไม่ใช่วิธีอื่น ๆ
— ดั๊ก
@SpencerRathbun ขอบคุณ! ฉันจะต้องดูที่ ไม่มากที่ฉันรัก svn เนื่องจากฉันมีความไม่พอใจกับคอมไพล์
— maple_shaft
10
@Spencer - Contrariwise ในฐานะผู้ใช้ทั้งคู่gitและhgฉันขอแนะนำMercurialสำหรับทุกคนที่คิดว่าgitมากเกินไป TortoiseHGจะเป็นที่คุ้นเคยสำหรับทุกคนที่เคยใช้TortoiseSVN (แม้จะใช้การซ้อนทับ Explorer เดียวกันบน Windows) แน่นอนว่าง่ายกว่า VSS มากและฉันจะแปลกใจถ้าใช้เวลามากกว่าสองสามวินาทีในการตั้งค่า repo hg กำหนดสถานะเริ่มต้นและโคลนไปยังไดรฟ์ที่ใช้ร่วมกัน
— Mark Booth
@ MarkBooth ตามที่ระบุไว้ในคำถามเดิมฉันคิดว่ามันเป็นเรื่องของความต้องการและความต้องการ ที่ทำงานปัจจุบันของฉันไม่มีการซื้อคืนก่อนที่จะไปถึงที่นั่น ฉันต้องการบางสิ่งบางอย่างที่มีทั้งหมดหรือส่วนใหญ่เครื่องมือโครงการที่ฉันต้องการรวมเข้าด้วยกันใช้งานง่ายเก็บทุกอย่างแทนที่จะเป็นสันดอนและจะแจกจ่ายให้กับทีมที่มี 1 หรือ 2 คนในหลาย ๆ เครื่อง
— Spencer Rathbun
20

นี่คือญาติทั้งหมดและเหมือน maple_shaft พูดว่าถ้าใครเหมาะกับคุณอย่าเปลี่ยน!

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

— โกง
แหล่งที่มา
2
SVN จัดการกับพวกเขาได้ดีขึ้นอย่างไร Git พิจารณา BLOB ทุกไฟล์
— WarrenT
4
@WarrenT เนื่องจากเวิร์กโฟลว์โดยมีคอมไพล์คุณแยกและรวมจำนวนมาก (หรือทำไมต้องใช้มัน) และคุณไม่สามารถผสานไบนารีได้แนบเนียน ดังนั้นคุณมักจะใส่คุณสมบัติ "ต้องการล็อค" ในไฟล์ไบนารีใน SVN
— gbjbaanb
1
ไบนารีบางตัวสามารถผสานกันได้ (ในทางทฤษฎี) เช่นเอกสาร ODT
— Donal Fellows
18

การใช้งาน มันไม่ได้เป็นการทำบุญที่แท้จริงของการโค่นล้ม แต่เป็นTortoiseSVN 's .. TortoiseGit นั้นมีอยู่จริง แต่ก็ยังมีอีกทางที่จะไปจับคู่ TortoiseSVN ได้

ถ้าคุณถามว่า Git ไม่ดีกว่า SVN ฉันจะตอบGitHub มันตลกที่เครื่องมือของบุคคลที่สามสร้างความแตกต่างอย่างมาก

— Peter Mortensen
แหล่งที่มา
1
Assembla (สำหรับSCM ที่รองรับ - รายการ SVN) ดีกว่า github ฉันคิดว่า
— Lazy Badger
นอกจากนี้ยังมี SmartGit, GitXL ฯลฯ ตอนนี้โปรแกรมที่ทำให้การใช้วิธีคอมไพล์ง่ายขึ้น
— wirrbel
@ LazyBadger ไม่เคยได้ยินมาก่อน
— Pacerier
16

เมื่อคุณไม่ต้องการแยกสาขาและรวม SVN (กับTortoiseSVNบน Windows) นั้นง่ายต่อการเข้าใจและใช้งาน Git นั้นซับซ้อนเกินไปสำหรับกรณีง่าย ๆ เนื่องจากมันพยายามทำให้การแยก / รวมเข้าด้วยกันง่ายขึ้น

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

— Ian
แหล่งที่มา
8
การใช้การgitแยกและการผสานไม่ใช่การดำเนินการที่ซับซ้อน ฉันยังใช้สาขาในโครงการแบบคนเดียวแม้ว่าจะไม่มีข้อกำหนดสำหรับหลาย ๆ เวอร์ชันก็ตาม การทำงานคุณไม่สามารถดำเนินการต่อในสาขาในขณะที่แตกแขนงเมื่อคุณพบว่าการพยายามแก้ปัญหาอื่นอาจจะดีกว่า ... อย่างไรก็ตามฉันยอมรับว่าgitมันยากที่จะเรียนรู้
— maaartinus
เมื่อใดก็ตามที่คุณต้องการแก้ไขข้อผิดพลาดในเวอร์ชั่นเก่าคุณต้องทำการแยกและผสาน
1
ทำไมคนไม่พิจารณาความคิดที่ว่า mercurial นั้นง่ายกว่า svn หรือ git
— วอร์เรน P
ฉันคิดว่าส่วนหนึ่งเป็นเพราะ SVN มีจนกระทั่งเมื่อเร็ว ๆ นี้ไม่สนับสนุนการรวมสาขาและการรวมกันโดยไม่มีค่าใช้จ่ายสูงมากนักทำให้โปรแกรมเมอร์สามารถยืนต่อผู้จัดการได้มากขึ้นเมื่อพวกเขาต้องการเปลี่ยนแปลงสิ่งที่คนอื่นกำลังทำอยู่ เครื่องมือต้องทำงานภายในองค์กรของ บริษัท และช่วยกำหนดรูปแบบของ บริษัท
— เอียน
14

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

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

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

— Peter Mortensen
แหล่งที่มา
git เป็นแนวทาง "เชิงปรัชญา" มากกว่าในการควบคุมเวอร์ชัน คุณเริ่มคิดเกี่ยวกับความหมายของการกระทำกิ่งไม้ ฯลฯ ดังนั้นผู้ที่ต้องการใช้ VCS เป็น "การสำรองข้อมูล" และเครื่องมือการกระจายมีเวลาที่ยากขึ้น แต่คอมไพล์ไม่ยากมากขึ้น
— wirrbel
11

ที่ทำงานฉันไม่สามารถเปลี่ยนนักพัฒนาจาก SVN เป็นDVCSด้วยเหตุผลสองประการ:

  • การชำระเงินบางส่วน (เช่นโฟลเดอร์สามโฟลเดอร์ที่มีความลึกต่างกันในแผนผังโครงการ)
  • การล็อกไฟล์ (รายงานรูปแบบไบนารี)
— alexandrul
แหล่งที่มา
8
  • ความรู้สึกปลอดภัยเมื่อทำ 'svn กระทำ' ตั้งแต่คอมมิทไปที่เซิร์ฟเวอร์ไม่มีสกรูที่เป็นไปได้ที่ฉันสามารถทำได้ซึ่งจะลบการเปลี่ยนแปลงของฉันหลังจากที่คอมมิท ในคอมไพล์คอมมิชชันนั้นเป็นแบบท้องถิ่นดังนั้นจนกว่าฉันจะกดมันจะเป็น 'rm -rf' จรจัดและมันจบแล้ว
  • ความมุ่งมั่นมีการรับรองความถูกต้อง โดยค่าเริ่มต้นในคอมไพล์ฉันสามารถบอกได้ว่าฉันกระทำเป็นใคร
  • คำสั่งน้อยลงเพื่อเรียนรู้สำหรับการใช้ชีวิตประจำวัน 'svn checkout', 'svn up' และ 'svn commit' จะทำให้คุณอยู่ไกล
  • การชำระเงินที่ใช้ร่วมกันทำงานได้ดีกว่ามาก เมื่อคุณยอมรับมันจะขอชื่อผู้ใช้ / รหัสผ่านของคุณคุณไม่จำเป็นต้องจำรหัสผ่านบางบรรทัดคำสั่ง บางครั้งในที่ทำงานเรามีเครื่องที่ใช้ร่วมกันกับการชำระเงิน svn ที่ใช้ร่วมกันของบางโครงการ บางคนอาจพูดว่า "บ็อบคุณสามารถดูสิ่งนี้บนเครื่องนี้" และเขาสามารถทำได้และเขาสามารถยอมรับการเปลี่ยนแปลงของเขาในฐานะผู้ใช้ของเขาโดยไม่ต้องสกรู
  • เค้าโครงพื้นที่เก็บข้อมูล คุณสามารถมีโครงการร่มและโครงการย่อยและเลือกสิ่งที่จะตรวจสอบเมื่อ
  • หมายเลขการแก้ไขคือการเพิ่มจำนวนเต็ม
  • ออกแบบมาสำหรับเวิร์กโฟลว์ที่เก็บส่วนกลาง
— ทิม
แหล่งที่มา
+1 สำหรับปัญหาการตรวจสอบสิทธิ์ Git กระทำจะต้องมีการลงนามและการเซ็นจะต้องมีการตรวจสอบซึ่งเป็นเรื่องยาก
— คริสเตียน
6

คนอื่น ๆ โพสต์คำตอบที่ดีงาม แต่สิ่งที่เกี่ยวกับการอนุญาต? การใช้การโค่นล้มเหนือ SSH คุณสามารถสร้างบัญชีแยกต่างหากบนเซิร์ฟเวอร์ของคุณสำหรับ SVN นักพัฒนาที่แตกต่างกันสามารถให้สิทธิ์การเข้าถึงที่แตกต่างกันในส่วนต่าง ๆ ของที่เก็บ GIT สามารถทำเช่นนั้นได้หรือไม่ ฉันเดาว่ามี gitolite แต่ดูเหมือนจะไม่ยืดหยุ่นหรือแข็งแกร่งสำหรับฉันและฉันก็ไม่รู้จักใครที่ใช้งานจริง

— GlenPeterson
แหล่งที่มา
2
คนอื่น ๆ ได้เห็นสิ่งนี้โดยกล่าวถึง "การควบคุมการจัดการจากบนลงล่าง" นี่เป็นองค์ประกอบสำคัญสำหรับสภาพแวดล้อมของฉัน - เรามีพื้นที่บางส่วนของที่เก็บของเราที่ต้องล็อคลงเพื่ออ่านอย่างเดียวหรือไม่อ่านสำหรับกลุ่มผู้ใช้บางกลุ่ม นอกจากนี้เรายังต้องมีสถานที่ตั้งเดียวที่เราสามารถชี้และพูดว่า "นี่คือสำเนาต้นแบบที่เชื่อถือได้หากสำเนาของคุณไม่ตรงกับที่นี่มันไม่ใช่เป็นทางการ"
— alroc
1
พื้นที่เก็บข้อมูลที่มีความสุขของหัวหน้าโครงการและร้อยโทกำลังควบคุมผู้ที่สามารถกระทำได้ Git repo เผยแพร่บนเซิร์ฟเวอร์ที่เปิดใช้งาน http- รับรองความถูกต้อง (โดยใช้โมดูล apache เดียวกัน svn ทำ) ทำการตรวจสอบและบอกว่าใครสามารถโคลน / เช็คเอาต์อะไร แน่นอนว่ามันไม่ละเอียดเหมือน svn ต่อการอนุญาตของไดเรกทอรี แต่สำหรับฉันมันดูเหมือนการจัดการแบบไมโครมากกว่าความต้องการที่แท้จริง
— Hubert Kario
@HubertKario - นี่ทำให้เกิดคำถามว่า "โปรแกรมเมอร์ที่ดีที่สุดของคุณควรใช้เวลาตรวจสอบรหัสของคนอื่นหรือไม่" จริงๆแล้วฉันสนใจคำตอบของคำถามนี้มากที่ฉันโพสต์ไว้ที่นี่: programmers.stackexchange.com/questions/181817//
— GlenPeterson
5

ความเร็ว. บางครั้งใช้เวลา 10 หรือ 15 นาทีในการโคลนพื้นที่เก็บข้อมูล git ขนาดใหญ่ในขณะที่พื้นที่เก็บข้อมูลการโค่นล้มขนาดใกล้เคียงกันใช้เวลาสองสามนาทีในการตรวจสอบ

— calum_b
แหล่งที่มา
6
แต่การชำระเงิน / การโคลนเป็นการดำเนินการที่หายาก ในสถานการณ์ส่วนใหญ่ git นั้นเร็วกว่าการโค่นล้ม
— rds
5
git clone --depth=1เป็นเพื่อนของคุณถ้าคุณไม่สนใจประวัติศาสตร์
— Hubert Kario
4

ฉันโพสต์สิ่งนี้เป็นคำตอบมากกว่าความคิดเห็น

ฉันยอมรับว่า DVCS มีแนวโน้มค่อนข้างมากในตอนนี้ แต่ฉันจะพยายามบอกเหตุผล

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

อย่างไรก็ตามไม่ใช่ทุกโครงการซอฟต์แวร์ที่ดีเท่าที่ได้รับ:

  • โครงการระยะยาวได้รับประโยชน์มากมายจาก DVCS เนื่องจากใช้ค่าใช้จ่ายน้อยลงช่วยให้การจัดการดีขึ้นมาก (การแยกสาขา ฯลฯ ) และได้รับการสนับสนุนอย่างมากจากโฮสต์เช่น google code และ github

  • โครงการเหล่านั้นไม่เพียง แต่มีโครงการประเภทอื่น ๆ ที่ได้รับการพัฒนาใน บริษัท โดยไม่ได้รับความช่วยเหลือจากโลกภายนอกหรืออินเทอร์เน็ต: ทุกอย่างเกิดขึ้นภายในและบ่อยครั้งในระยะสั้น ตัวอย่างที่ดี: วิดีโอเกม รหัสวิวัฒนาการอย่างรวดเร็ว

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

  • นักพัฒนามีเครื่องจักรที่เป็นของ บริษัท และสิ่งนี้อาจเปลี่ยนแปลงอย่างรวดเร็ว การกำหนดค่า repo จะเสียเวลา
  • หากพวกนั้นไม่มีเครื่องจักรของตัวเองพวกเขามีโอกาสน้อยที่จะทำงานบนซอร์สโค้ด / ส่วนเดียวกันของโครงการ บวกหนึ่งสำหรับข้อมูลส่วนกลาง
  • ความเร็วเครือข่ายและเงินจำนวนมากช่วยให้การใช้เซิร์ฟเวอร์รวมศูนย์ที่จัดการกับทุกอย่าง SVN มันเป็นการปฏิบัติที่ไม่ดี แต่การสำรองข้อมูลจะทำ ฯลฯ
  • SVN นั้นใช้ง่ายกว่าแม้ว่าจะเป็นวิธีที่ผิด: การซิงโครไนซ์ไฟล์กับเพื่อนที่ไม่มีความซ้ำซ้อนไม่ใช่ปัญหาง่ายๆและ "ทำในสิ่งที่ถูกต้อง" ไม่สามารถทำได้ทันเวลาหากคุณต้องการให้มันสมบูรณ์แบบเสมอ

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

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

— jokoon
แหล่งที่มา
คุณสามารถอธิบายตัวอย่างอุตสาหกรรมเกมได้หรือไม่
— johnny
3

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

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

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

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

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

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

ในที่สุดฉันก็พบว่าการใช้งานร่วมกันโดยใช้การพัฒนาห้องสมุด "ร้อน" ภายใต้ Svn (ด้วย CI และวิธีการทดสอบที่ขับเคลื่อนด้วย) ช่วยให้ก้าวของการประสานงานการพัฒนาที่ยากต่อการบรรลุผลด้วยทีมที่กระจายมากขึ้น

— วิลเลียมเพน
แหล่งที่มา
2

ด้านล่างเป็นสองเหตุผลที่ฉันยังคงอยู่กับ SVN

  1. เส้นโค้งการเรียนรู้ SVN นั้นง่ายกว่า Git แม้แต่การตั้งค่า (เซิร์ฟเวอร์หรือไคลเอนต์ด้วย) การใช้งานและคำสั่ง
  2. แพ็คเกจเซิร์ฟเวอร์ที่ดีกว่าเช่นSubversion Edge , VisualSVN , uberSVNเป็นต้น
— Shiba
แหล่งที่มา
1
+1 สำหรับ # 1 เปรียบเทียบ SVN กับ GIT ไดอะแกรมที่นี่steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git
— s_t_e_v_e
1

มีแนวโน้มที่สำคัญสองประการในการควบคุมเวอร์ชันในขณะนี้ จัดจำหน่ายและบูรณาการ

Git นั้นยอดเยี่ยมในการกระจายอำนาจ

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

เครื่องมือที่ทำสิ่งนี้กับ SVN นั้นมีความสมบูรณ์และใช้งานได้ทุกวัน

— Sean McMillan
แหล่งที่มา
-1

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

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

ไม่จำเป็นต้องมีอันตรายจากการสูญเสียข้อมูล ตะขอ pre-revprop-change และ post-revprop-change สามารถบันทึกประวัติของข้อความเก่าถ้าคุณกังวลหรือส่งอีเมลที่มีข้อความบันทึกต่างกัน (นี่เป็นเรื่องธรรมดามาก) เพื่อให้มี หลักฐานการตรวจสอบ

— Karl Fogel
แหล่งที่มา
1
นี่เป็นเรื่องง่ายที่จะทำด้วยคอมไพล์ เช่น git - แก้ไข; อีกวิธีในการทำเช่นนี้คือผ่านการรีเซ็ต git - soft HEAD ^ ซึ่งเพิ่งกลับมา แต่ไม่เปลี่ยนดัชนีดังนั้นคุณสามารถแก้ไข / เขียนข้อความคอมมิทใหม่ได้
— doug
สวัสดีคุณ doug ใช่คุณสามารถทำได้เพื่อที่เก็บข้อมูลในพื้นที่ของคุณ แต่ฉันกำลังพูดถึงเมื่อคุณผลักการเปลี่ยนแปลงที่อื่น - "คอมไพล์คอมมิท - แก้ไข" ไม่ได้ช่วยอะไรคุณมากแล้ว ใน SVN คุณสามารถแก้ไขข้อความบันทึกบนเซิร์ฟเวอร์กลางได้อย่างแม่นยำเนื่องจากมีแนวคิดของเซิร์ฟเวอร์กลาง นั่นคือสิ่งที่ฉันหมายถึงโดย "เป็นไปไม่ได้โดยการออกแบบในระบบการกระจายอำนาจ" ฉันจะแก้ไขคำตอบเพื่อให้ชัดเจนยิ่งขึ้น
— Karl Fogel
1
ฉันรักวิธีการ "ที่คุณสามารถเล่น ๆ ที่มีประวัติ" ถูกกล่าวหาว่าคุณลักษณะ ฉันคิดว่ามันเป็นข้อผิดพลาดถ้ามันไม่ได้ตั้งใจ
— cHao
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.