คำถามติดแท็ก svn

ฉันพยายามเข้าใจถึงประโยชน์ของระบบควบคุมรุ่นแจกจ่าย (DVCS) ฉันพบว่าการโค่นล้ม Re-educationและบทความนี้โดยMartin Fowlerมีประโยชน์มาก Mercurial และ DVCS อื่น ๆ โปรโมตวิธีใหม่ในการทำงานกับโค้ดด้วยเซ็ตการแก้ไขและการคอมมิชชันท้องถิ่น มันป้องกันการรวมนรกและปัญหาการทำงานร่วมกันอื่น ๆ เราไม่ได้รับผลกระทบจากสิ่งนี้เนื่องจากฉันฝึกการรวมกลุ่มอย่างต่อเนื่องและทำงานคนเดียวในสาขาเอกชนไม่ใช่ตัวเลือกเว้นแต่ว่าเรากำลังทำการทดลอง เราใช้สาขาสำหรับทุกรุ่นสำคัญซึ่งเราจะแก้ไขข้อบกพร่องที่รวมเข้ากับลำต้น Mercurial อนุญาตให้คุณมีผู้หมวด ฉันเข้าใจว่าสิ่งนี้มีประโยชน์สำหรับโครงการขนาดใหญ่มากเช่น Linux แต่ฉันไม่เห็นคุณค่าในทีมขนาดเล็กและการทำงานร่วมกันสูง (5 ถึง 7 คน) Mercurial เร็วกว่าใช้พื้นที่ดิสก์น้อยลงและการทำสำเนาโลคัลเต็มรูปแบบช่วยให้สามารถบันทึกและดำเนินการได้เร็วขึ้น ฉันไม่ได้กังวลเรื่องนี้เช่นกันเนื่องจากฉันไม่ได้สังเกตเห็นความเร็วหรือปัญหาเกี่ยวกับพื้นที่ของ SVN แม้ว่าจะมีโครงการขนาดใหญ่มากที่ฉันกำลังทำงานอยู่ ฉันกำลังมองหาประสบการณ์ส่วนตัวและ / หรือความคิดเห็นของคุณจากอดีต SVN โดยเฉพาะอย่างยิ่งเกี่ยวกับแนวคิดเซ็ตการแก้ไขและประสิทธิภาพโดยรวมที่คุณวัดได้ UPDATE (วันที่ 12 มกราคม) : ตอนนี้ฉันเชื่อว่ามันคุ้มค่าที่จะลอง UPDATE (12 มิ.ย. ) : ฉันจูบ Mercurial และฉันชอบมัน รสชาติของเชอร์รี่ท้องถิ่นของเขามุ่งมั่น ฉันจูบ …

300 version-control  git  mercurial  dvcs  svn 

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

131 version-control  git  svn  builds  versioning 

ฉันทำงานในสถาบันของรัฐ เทคโนโลยีที่ใช้อยู่ที่นี่และวิธีการพัฒนาซอฟต์แวร์นั้นค่อนข้างล้าสมัย มีพื้นที่เก็บข้อมูลมากมาย แต่ไม่มีพื้นที่ที่เหมาะสมในการเก็บและบำรุงรักษาแอปพลิเคชันที่ใช้ในการทำงานส่วนใหญ่โดยอัตโนมัติที่นี่ สถาบันไม่อนุญาตให้ฉันใช้ซอฟต์แวร์ SCM เช่น GIT หรือ SVN อะไรจะเป็นวิธีที่ดีที่สุดในการรักษาคุณภาพรหัสและสามารถเพิ่มคุณสมบัติใหม่ในแอปได้ในภายหลัง ฉันจะจำการเปลี่ยนแปลงที่ทำกับรหัสโดยไม่ทำลายได้อย่างไร แก้ไข: ฉันลืมที่จะพูดถึงพวกเขามีไดรฟ์เครือข่ายสำหรับคอมพิวเตอร์แต่ละเครื่องและอย่างใดไดรฟ์เครือข่ายเหล่านี้ทำหรือบันทึกการสำรองข้อมูลในช่วงเวลา อย่างไรก็ตามหากฉันไม่ได้สร้างแผนของตัวเองเพื่อให้สามารถบันทึกงานของฉันและสามารถเพิ่มคุณสมบัติใหม่โดยไม่ทำลายโค้ดที่มีอยู่แล้วก็ไม่มีข้อได้เปรียบที่เหนือกว่าโซลูชัน SCM แก้ไข: เนื่องจากหลายคนแนะนำ Git พกพาฉันต้องเพิ่มข้อมูลเพิ่มเติม ฉันพยายามติดตั้งเซิร์ฟเวอร์ Visual SVN แต่ล้มเหลวเนื่องจากฉันไม่มีสิทธิ์ของผู้ดูแลระบบในการติดตั้ง ฉันพยายามดาวน์โหลด Git shell ปกติ แต่ไฟร์วอลล์หรือการตั้งค่าเครือข่ายไม่อนุญาตให้ฉันเข้าถึงหน้าดาวน์โหลด Git ฉันยังลองส่ง Git พกพาไปยังอีเมลซึ่งก็คือ Gmail Google ตรวจพบไฟล์ exe ในแพ็คเกจและมันก็ไม่อนุญาตให้ฉันดาวน์โหลด Git เวอร์ชั่นพกพาบนคอมพิวเตอร์ที่ทำงานของฉัน อีกสิ่งหนึ่งที่ฉันต้องพูดถึงคือนโยบายเครือข่ายที่ใช้กับคอมพิวเตอร์ที่สถาบันไม่อนุญาตให้ใช้การจัดเก็บ USB devces คุณสามารถใช้พอร์ต USB เพื่อชาร์จสมาร์ทโฟนหรือใช้พลังงานบางอย่างเช่นลำโพงขนาดเล็ก เช่นเดียวกับบางคนที่กล่าวถึงมีคอมพิวเตอร์ที่ไม่อนุญาตแม้แต่อินเทอร์เน็ต

110 git  code-quality  svn  scm 

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

84 tools  version-control  git  svn 

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

78 git  svn 

ฉันต้องการทราบว่าวิธีจัดการกับไฟล์ต้นฉบับที่ต้องลบออกจากการควบคุมเวอร์ชันอาจถือได้ว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่ ฉันต้องการอธิบายให้คุณตามตัวอย่าง: เมื่อเร็ว ๆ นี้ฉันโกรธมากเพราะฉันต้องคัดแยกคลาส Java ในโปรแกรมที่มีรหัสตายโดยทั่วไป แต่มันไม่มีเอกสารและไม่ได้แสดงความคิดเห็นในคลาส Java เหล่านั้น แน่นอนว่าพวกเขาต้องถูกลบ แต่ก่อนที่ฉันจะลบสิ่งที่ซ้ำซ้อนฉันมี - บางคนอาจพูดว่าแปลก - นิสัย: ฉันจะไม่ลบไฟล์ที่ซ้ำซ้อนดังกล่าวทันทีผ่านทาง SVN-> ลบ (แทนที่ด้วยคำสั่งลบของระบบควบคุมเวอร์ชันที่คุณเลือก) แต่ให้ใส่ความคิดเห็นในไฟล์เหล่านั้นแทน (ฉันอ้างอิงทั้งที่หัวและท้ายกระดาษ) ว่าพวกเขากำลังจะไป ถูกลบ + ชื่อของฉัน + วันที่และ - ที่สำคัญกว่า - ทำไมพวกเขาถึงถูกลบ (ในกรณีของฉันเพราะพวกเขาตายรหัสสับสน) จากนั้นฉันบันทึกและส่งไปยังการควบคุมเวอร์ชัน ครั้งต่อไปเมื่อฉันต้องคอมมิต / เช็คอินบางอย่างในโปรเจ็กต์ถึง version control ฉันกด SVN-> Delete จากนั้นพวกมันก็จะถูกลบใน Version Control - ซึ่งแน่นอนว่ายังคงสามารถเรียกคืนผ่านการแก้ไขได้ ทำไมต้องทำเช่นนี้แทนที่จะลบออกทันที เหตุผลของฉันคือฉันต้องการมีเครื่องหมายอย่างชัดเจนอย่างน้อยที่สุดในการแก้ไขครั้งล่าสุดซึ่งมีไฟล์ที่ซ้ำซ้อนเหล่านั้นอยู่ทำไมพวกเขาจึงสมควรถูกลบ หากฉันลบทันทีพวกเขาจะถูกลบ …

53 version-control  svn  evidence-based 

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

50 issue-tracking  workflows  svn 

หนึ่งในเหตุผลที่โปรแกรมเมอร์ชอบ SVN มากกว่า CVS คืออดีตยอมให้มีการปรมาณู สิ่งนี้หมายความว่า ?

34 svn  versioning  cvs 

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

34 git  svn  continuous-integration  dvcs  branching 

ฉันทำงานในแผนกที่ไม่มีใครเคยใช้การควบคุมซอร์สมาก่อนรวมถึงตัวฉันด้วย ฉันพยายามผลักดันแนวคิดนี้ ฉันใช้เวลาไปกับการค้นคว้า SVN ฉันได้เรียนรู้พื้นฐานบางอย่างแล้ว ฉันสามารถสร้าง / อัพเดท / ชำระเงิน / ส่งด้วยบรรทัดคำสั่งและจาก Tortoise ฉันเริ่มเรียนรู้วิธีติดแท็กและสาขา แต่ยังสับสนมากเกี่ยวกับความขัดแย้งระหว่างกิ่งและลำตัว ฯลฯ ฉันยังคงเรียนรู้ แต่ฉันไม่มีบุคคลที่สามารถแสดงอะไรให้ฉันได้ มันมาจากหนังสือ / บทช่วยสอนและการลองผิดลองถูก จากสิ่งที่ฉันได้อ่านออนไลน์ดูเหมือนว่าgitเป็นสิ่งที่ดีกว่าที่จะรู้ แต่มันก็ซับซ้อนกว่าด้วย ฉันไม่ต้องการที่จะเอาชนะตัวเอง ฉันควรจะยังคงเป็นผู้เชี่ยวชาญต่อก่อนที่จะย้ายไปที่คอมไพล์หรือฉันจะฉลาดกว่าที่จะข้ามไปคอมไพล์หรือไม่? มีข้อดีข้อเสียของทั้งสองวิธีหรือไม่?

31 svn  git 

ฉันเพิ่งมาข้ามบทความ MSDN เกี่ยวกับการแยกทางและการผสานและ SCM: การแตกแขนงและผสานรองพื้น - คริส Birmele ในบทความพวกเขาบอกว่า 'บิ๊กแบงผสาน' เป็นปฏิปักษ์ต่อการรวม: Big Bang Merge - ชะลอการรวมสาขาเพื่อสิ้นสุดความพยายามในการพัฒนาและพยายามรวมสาขาทั้งหมดพร้อมกัน ฉันรู้ว่านี่คล้ายกับสิ่งที่ บริษัท ของฉันทำกับสาขาการพัฒนาทั้งหมดที่ผลิต ฉันทำงานที่ บริษัท ขนาดเล็กมากโดยมีคนคนหนึ่งทำหน้าที่เป็นผู้ตรวจสอบขั้นสุดท้าย + มีอำนาจในการรวมลำตัว เรามีนักพัฒนา 5 คน (รวมถึงฉันด้วย) เราแต่ละคนจะได้รับมอบหมายภารกิจ / ข้อบกพร่อง / โครงการแยกจากกันและเราจะแยกแต่ละสาขาออกจากเส้นทางปัจจุบัน (การโค่นล้ม) จากนั้นทำการพัฒนาในสาขาของเราทดสอบผลลัพธ์เขียนเอกสาร หากจำเป็นให้ดำเนินการตรวจสอบแบบเพียร์และข้อเสนอแนะกับนักพัฒนาอื่น ๆ แล้วส่งสาขาสำหรับความคิดเห็น + ผสานในซอฟต์แวร์การจัดการโครงการของเรา เจ้านายของฉันซึ่งเป็นผู้มีอำนาจ แต่เพียงผู้เดียวในที่เก็บ trunk จะทำการตรวจสอบความคิดเห็นทั้งหมดของสาขาจนกว่าจะถึงจุดเดียวในเวลาที่เขาจะแสดงความคิดเห็นให้มากที่สุดเท่าที่จะทำได้บางสาขาจะถูกโยนทิ้งเพื่อปรับปรุง / แก้ไข กิ่งไม้จะถูกรวมเข้ากับลำต้นบางสาขาจะถูกโยนกลับเนื่องจากความขัดแย้ง ฯลฯ ไม่ใช่เรื่องแปลกที่เราจะมีสาขาที่ใช้งานอยู่ 10-20 …

28 svn  anti-patterns  merging  scm 

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

28 version-control  teamwork  svn 

สำเนาซ้ำที่เป็นไปได้: ฉันเป็นผู้ที่ถูกโค่นล้มทำไมฉันจึงควรพิจารณาหรือไม่พิจารณา Mercurial หรือ Git หรือ DVCS อื่น ๆ ทุกครั้งที่คุณได้ยินคนพูดว่าการควบคุมเวอร์ชันแบบกระจาย (Git, HG) นั้นดีกว่าการควบคุมเวอร์ชั่นแบบรวมศูนย์ (เช่น SVN) เนื่องจากการรวมกันนั้นยากและเจ็บปวดใน SVN สิ่งนี้คือฉันไม่เคยมีปัญหาใด ๆ กับการรวมใน SVN และเนื่องจากคุณเคยได้ยินการอ้างสิทธิ์ที่ทำโดยผู้สนับสนุน DVCS และไม่ใช่ผู้ใช้ SVN จริงมันมีแนวโน้มที่จะเตือนฉันเกี่ยวกับโฆษณาที่น่ารังเกียจบนทีวีที่พวกเขา พยายามขายสิ่งที่คุณไม่ต้องการโดยให้นักแสดงทำผิดพลาดแสร้งทำเป็นว่าสิ่งที่คุณมีอยู่แล้วและใช้งานได้ดีใช้ยากอย่างไม่น่าเชื่อ และกรณีการใช้งานที่นำขึ้นมาอย่างสม่ำเสมอคือการรวมสาขาอีกครั้งหนึ่งซึ่งทำให้ฉันนึกถึงโฆษณาผลิตภัณฑ์ฟางแมนอีกครั้ง หากคุณรู้ว่าคุณกำลังทำอะไรคุณไม่ควร (และไม่ควรต้อง) รวมสาขาในตอนแรก (แน่นอนว่ามันยากที่จะทำเมื่อคุณทำอะไรผิดพลาดและไร้สาระ!) ดังนั้นการลดกรณีการใช้ชาวฟางที่ไร้สาระมีอะไรบ้างในการรวม SVN ที่ยากกว่าการรวมในระบบ DVCS โดยรวม

28 git  svn  mercurial  dvcs  merging 

ฉันค้นหาและไม่สามารถหาเหตุผลทางธุรกิจใด ๆ ได้ว่าทำไมระบบ git / mercurial / bazzr จึงดีกว่าระบบรวมศูนย์ (การโค่นล้มการบังคับใช้) ถ้าคุณกำลังพยายามที่จะขาย DVCS ไปยังบุคคลที่ไม่ใช่ทางด้านเทคนิคสิ่งที่ข้อโต้แย้งที่คุณจะจัดให้มีการ DVCS กำไรที่เพิ่มขึ้น ฉันจะขว้างคอมไพล์ให้กับผู้จัดการของฉันในไม่ช้ามันจะใช้เวลาสักครู่ในการแปลงคลังเก็บโค่นล้มและค่าใช้จ่ายในการซื้อใบอนุญาต smartgit แก้ไขฉันพยายามทำให้คำถามนี้เป็นการสนทนาทั่วไปเกี่ยวกับการรวมศูนย์และการกระจายอำนาจ แต่ก็หลีกเลี่ยงไม่ได้ที่จะกลายเป็นการโค่นล้มของ Git vs แน่นอนว่ามีระบบรวมศูนย์ที่ดีกว่าการโค่นล้ม

26 version-control  mercurial  dvcs  svn  git 

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

25 version-control  git  svn  branching