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

ฉันพยายามเข้าใจถึงประโยชน์ของระบบควบคุมรุ่นแจกจ่าย (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 

เมื่อดูที่การเปรียบเทียบดูเหมือนว่าฉันอาจมีการแมป 1: 1 ระหว่างชุดคุณลักษณะของพวกเขา แต่ข้อความที่อ้างถึงบ่อยครั้งก็คือ "Mercurial is easy" พื้นฐานของข้อความนี้คืออะไร? (ถ้ามี)

204 git  mercurial 

ในช่วงไม่กี่ปีที่ผ่านมาการโฆษณารอบ ๆ Git เพิ่มขึ้นอย่างมาก ทุกคนรู้เกี่ยวกับ Git ไม่มีใครรู้เกี่ยวกับทางเลือก คนอื่น ๆ เช่น Mercurial ดูเหมือนจะไม่มีใครสังเกตเห็น ทั้งสองได้รับการปล่อยตัวในปี 2005 และมีฟังก์ชั่นที่คล้ายกัน ยิ่งไปกว่านั้น Mercurial ได้รับการพิจารณาว่าใช้งานได้ง่ายขึ้นใช้งานง่ายกว่าเดิม ดังนั้นจึงสามารถสันนิษฐานได้ว่าสิ่งนี้จะเป็นทางเลือกยอดนิยมโดยเฉพาะอย่างยิ่งสำหรับผู้ที่เพิ่งเริ่มการควบคุมเวอร์ชันแบบกระจาย ถึงกระนั้นดูเหมือนว่าคนส่วนใหญ่จะไม่รู้จักซึ่งแตกต่างจาก Git ที่ประสบความสำเร็จค่อนข้างดี จุดสำคัญของโพสต์นี้คือพยายามทำความเข้าใจปรากฏการณ์นี้ให้ดีขึ้น Git มาได้อย่างไรส่วนหนึ่งของเค้ก? พวกเขาใช้การตลาดที่ดีกว่าอย่างใด? เป็นเพราะชุมชนของมันมีมากขึ้น ... อะแฮ่ม ... "verbose"? เป็นเพราะชื่อ "Linus" หรือไม่? เป็นเพราะภาพลักษณ์ที่เกินบรรยายหรือไม่? ความคิดเห็นของคุณคืออะไร

124 version-control  git  mercurial 

เกือบทุกบทความที่ฉันได้อ่าน1 การเปรียบเทียบ Git และ Mercurial ดูเหมือนว่า Mercurial จะมีบรรทัดคำสั่ง UX ที่ดีกว่าโดยที่แต่ละคำสั่งถูก จำกัด เพียงหนึ่งแนวคิดเท่านั้น (ต่างจากที่พูดgit checkout) แต่เมื่อถึงจุดหนึ่ง Git ก็เริ่มได้รับความนิยมสูงสุดและจำนวนผู้ส่ง Git บนกราฟ Debian popcon (ดูภาพกราฟด้านล่าง) ระเบิดอย่างแท้จริง ที่มา: Debian เกิดอะไรขึ้นในปี 2010-01 ว่ามีการเปลี่ยนแปลงอย่างกระทันหัน ดูเหมือนว่า GitHub ก่อตั้งขึ้นเร็วกว่านั้นในปี 2008

86 git  history  mercurial 

ปี 2555! Mercurial และ Git ยังแข็งแกร่งอยู่ ฉันเข้าใจการแลกเปลี่ยนของทั้งสอง ฉันก็เข้าใจว่าทุกคนมีความชอบเหมือนกัน ไม่เป็นไร. ฉันกำลังมองหาข้อมูลเกี่ยวกับระดับการใช้งานของทั้งคู่ ตัวอย่างเช่นในstackoverflow.comการค้นหาGitทำให้คุณได้รับ 12000 เพลงMercurialทำให้คุณได้รับ 3000 Google Trendsกล่าวว่ามันเป็น 1.9: 1.0 สำหรับ Git ข้อมูลเชิงประจักษ์อื่นใดที่สามารถใช้ประมาณการการใช้สัมพัทธ์ของเครื่องมือทั้งสองได้

37 git  mercurial 

ฉันเคยใช้คอมไพล์มาก่อน แต่ฉันต้องการมีส่วนร่วมกับไพ ธ อนดังนั้นตอนนี้ฉันต้องเรียนรู้ Mercurial และฉันพบว่ามันน่าหงุดหงิดมาก ดังนั้นฉันจึงทำแผ่นแปะเล็ก ๆ สองสามชิ้นและฉันต้องการติดตามพวกเขาในคอมมิชชัน Mercurial Repository เห็นได้ชัดว่ามี4 วิธีที่จะจัดการกับการแตกแขนงในปรอท 1 และ 4 ดูไร้สาระอย่างสมบูรณ์สำหรับฉันสาขาชื่อดูเหมือนจะมีน้ำหนักมากและฉันรู้สึกว่าฉันไม่ควรใช้พวกเขาสำหรับการแก้ไข 1 คอมมิชชันที่รวดเร็วดังนั้นฉันจึงใช้บุ๊กมาร์ก ตอนนี้แพทช์ของฉันถูกปฏิเสธและฉันต้องการลบสาขาบุ๊กมาร์กของฉันจากที่เก็บของฉัน ตกลงใน git ฉันจะบังคับลบสาขาของฉันและลืมมันดังนั้นฉันลบบุ๊คมาร์คของฉันและตอนนี้ฉันมีปัญหาต่อไปนี้: TortoiseHG และhg logยังคงแสดงให้เห็นว่าการกระทำและdefaultสาขามี 2 หัว และถ้าฉันเข้าใจถูกต้องคุณจะไม่สามารถลบการคอมมิทเป็น hg หากไม่มีปลั๊กอินเพิ่มเติม Mercurial ไม่เพียง แต่แฮช แต่ยังปรับปรุงหมายเลข ในขณะที่ฉันเพิ่มความมุ่งมั่นของตัวเองสองสามข้อความมุ่งมั่นทั้งหมดที่ดึงมาหลังจากนั้นมีหมายเลขการแก้ไขที่แตกต่างจาก repo ส่วนกลางหลัก ฉันhg updateดึงหลังจากย้ายmasterบุ๊กมาร์กของฉันไปยังการคอมมิชชันล่าสุดโดยอัตโนมัติ แต่ฉันไม่สามารถหาวิธีที่จะทำได้ใน TortoiseHG ผมทำอะไรผิดหรือเปล่า? นี่เป็นเรื่องปกติและคาดหวังและฉันควรจะเพิกเฉยต่อปัญหาเหล่านี้หรือไม่ หรือฉันจะทำงานกับสาขาของฉันได้อย่างไร

32 git  mercurial  dvcs  branching 

ฉันอยากรู้ว่ามันเหมาะสมหรือไม่ที่จะแบ่งโครงการที่ฉันทำงานในที่เก็บสองแห่งแทนที่จะเป็นหนึ่งโครงการ จากสิ่งที่ฉันสามารถพูดได้: ส่วนหน้าจะถูกเขียนเป็น html + js แบ็กเอนด์ใน. net แบ็กเอนด์ไม่ได้ขึ้นอยู่กับส่วนหน้าและส่วนหน้าไม่ได้ขึ้นอยู่กับส่วนแบ็คเอนด์ ส่วนหน้าจะใช้ API พักผ่อนหย่อนใจดำเนินการในแบ็กเอนด์ ส่วนหน้าสามารถโฮสต์บนเซิร์ฟเวอร์ HTTP ใด ๆ คงที่ ณ ตอนนี้ที่เก็บมีโครงสร้างนี้: ราก: ส่วนหน้า / * แบ็กเอนด์ / * ฉันคิดว่ามันเป็นความผิดพลาดที่ทำให้โครงการทั้งสองอยู่ในที่เก็บเดียวกัน เนื่องจากโปรเจ็กต์ทั้งสองไม่มีการขึ้นต่อกันระหว่างกันดังนั้นจึงควรอยู่ในที่เก็บแต่ละรายการและหากจำเป็นต้องมีที่เก็บพาเรนต์ที่มีซับโดเลชัน ฉันได้รับแจ้งว่าไม่มีประโยชน์และเราจะไม่ได้รับประโยชน์ใด ๆ จากการทำเช่นนั้น นี่คือข้อโต้แย้งของฉัน: เรามีสองโมดูลที่ไม่ได้พึ่งพากัน การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา) ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีคนกดไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า) นักพัฒนาซอฟต์แวร์หนึ่งรายอาจใช้งานได้เฉพาะในแบ็กเอนด์ แต่จะต้องดึงส่วนหน้าหรือวิธีอื่น ๆ เสมอ ในระยะยาวเมื่อถึงเวลาต้องปรับใช้ ในบางวิธีส่วนหน้าสามารถปรับใช้กับเซิร์ฟเวอร์แบบคงที่หลายตัวในขณะที่มีเซิร์ฟเวอร์ส่วนหลังหนึ่งตัว ในทุกกรณีผู้คนจะถูกบังคับให้โคลนทั้งแบ็กเอนด์ด้วยหรือเพื่อให้สคริปต์ที่กำหนดเองเพื่อผลักดันให้เซิร์ฟเวอร์ทั้งหมดส่วนหน้าเท่านั้นหรือเพื่อลบแบ็กเอนด์ ง่ายกว่าเพียงแค่กด / ดึงเฉพาะส่วนหน้าหรือส่วนหลังกว่าทั้งสองอย่างหากจำเป็นต้องใช้เพียงส่วนเดียว …

30 project-management  version-control  git  mercurial  organization 

สำเนาซ้ำที่เป็นไปได้: ฉันเป็นผู้ที่ถูกโค่นล้มทำไมฉันจึงควรพิจารณาหรือไม่พิจารณา 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 

ฉันเห็นด้วยเสมอกับมนต์ของ Mercurial 1อย่างไรก็ตามตอนนี้ Mercurial มาพร้อมกับส่วนขยายการปฏิเสธและเป็นวิธีปฏิบัติที่นิยมในคอมไพล์ฉันสงสัยว่ามันอาจจะถือว่าเป็น "การปฏิบัติที่ไม่ดี" หรืออย่างน้อยก็ ไม่ดีพอที่จะหลีกเลี่ยงการใช้ ไม่ว่าในกรณีใดฉันรู้ว่าการรีบูตเป็นอันตรายหลังจากการผลัก OTOH ฉันเห็นจุดของการพยายามทำแพ็คเกจ 5 ที่กระทำในอันเดียวเพื่อทำให้มันดู niftier (โดยเฉพาะในสาขาการผลิต) อย่างไรก็ตามโดยส่วนตัวฉันคิดว่าจะดีกว่าถ้าได้เห็นบางส่วนที่ทำหน้าที่บางอย่าง การทดลองเสร็จสิ้นแม้ว่าจะไม่ได้ดี แต่การเห็นบางสิ่งเช่น "พยายามทำวิธีที่ X แต่ไม่เหมาะสมเท่ากับ Y หลังจากทั้งหมดการทำ Z ที่ใช้ Y เป็นฐาน" IMHO มีคุณค่าต่อผู้เรียน codebase และติดตามการพัฒนาความคิด ทัศนะของฉัน (ในแง่โง่, เกี่ยวกับอวัยวะภายใน, เอนเอียง) คือโปรแกรมเมอร์ที่ชอบลดการซ่อนข้อผิดพลาด ... และฉันไม่คิดว่ามันดีสำหรับโครงการเลย ดังนั้นคำถามของฉันคือ: คุณพบว่ามีค่าจริงๆที่จะมี "การกระทำอินทรีย์" (เช่นประวัติที่ไม่ได้รับการแก้ไข) ในทางปฏิบัติหรือไม่หรือตรงกันข้ามคุณชอบที่จะพบกับความมุ่งมั่นที่ดีและไม่สนใจกระบวนการทดลอง แล้วแต่อย่างใดอย่างหนึ่งที่คุณเลือกเหตุผลที่ไม่ทำงานสำหรับคุณ? (ให้สมาชิกในทีมคนอื่น ๆ เก็บประวัติหรืออีกทางหนึ่งคือรีบูทมัน) 1ต่อการวิเคราะห์ของ Google DVCSใน …

26 git  mercurial  dvcs 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา บริบท: ฉันอยู่ในชั้นปีที่ 3 ของวิทยาลัย นักเรียนแบ่งออกเป็นกลุ่มละ 4 คนเกือบทุกคนจะทำงานภายใต้หน้าต่าง (ยกเว้นบางคนที่อยู่บน linux) เป็นส่วนหนึ่งของหลักสูตรของโรงเรียนเราจะเริ่มต้นทำงานในโครงการสำหรับลูกค้าจริง แต่ฉันและทีมอื่นกำลังสงสัยว่าวิธีใดที่ดีที่สุดสำหรับการแบ่งปันรหัสของเรากับแต่ละอื่น ๆ ฉันทำงานพาร์ทไทม์เป็นเวลา 3 ปีและมีประสบการณ์มากมายในการใช้ทั้งคอมไพล์และ Mercurial ในโปรเจคที่แตกต่างกันดังนั้นฉันจึงไม่มีปัญหาในการใช้ระบบใดระบบหนึ่งหรือระบบอื่น อย่างไรก็ตามเพื่อนร่วมทีมของฉันไม่เคยใช้ระบบควบคุมเวอร์ชันมาก่อน นอกจากนี้ยังมีทีมอื่นที่พยายามใช้ SVN แต่มีปัญหาใหญ่และอยากลองใช้อย่างอื่นดังนั้นพวกเขาจึงถามความคิดเห็นของฉัน ความคิดของฉัน: ฉันได้ยินมาว่า Mercurial + TortoiseHg มีการรวมที่ดีขึ้นภายใต้ windows แต่ฉันสงสัยว่าแนวคิดของหัวหน้าที่ไม่ระบุชื่ออาจทำให้พวกเขาสับสนแม้ว่าฉันจะอธิบาย ในทางกลับกันฉันพบว่ากิ่ง git นั้นง่ายกว่าสำหรับผู้เริ่มต้นที่จะเข้าใจ (แยกการทำงานที่ชัดเจนสำหรับโปรแกรมเมอร์แต่ละคน) แต่ไม่สามารถทำงานได้ดีในหน้าต่าง

25 version-control  git  mercurial 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา มีอ่านฉัน geek โค่นล้มทำไมฉันจึงควรพิจารณาหรือไม่พิจารณา Mercurial หรือ Git หรือ DVCS ฉันมีคำถามติดตามที่เกี่ยวข้อง ฉันอ่านคำถามนั้นและอ่านลิงก์และวิดีโอที่แนะนำและฉันเห็นประโยชน์ แต่ฉันไม่เห็นภาพรวมผู้คนที่กำลังพูดถึง ทีมงานของเรามีนักพัฒนา 8-10 คนที่ทำงานบนฐานรหัสขนาดใหญ่หนึ่งโครงการซึ่งประกอบด้วย 60 โครงการ เราใช้การโค่นล้มและมีลำตัวหลัก เมื่อนักพัฒนาเริ่มกรณี Fogbugz ใหม่พวกเขาสร้างสาขา svn ทำผลงานในสาขาและเมื่อพวกเขาทำเสร็จพวกเขารวมกลับไปที่ลำต้น บางครั้งพวกเขาอาจอยู่ในสาขาเป็นเวลานานและรวมลำตัวกับสาขาเพื่อรับการเปลี่ยนแปลง เมื่อฉันดู Linus พูดคุยเกี่ยวกับผู้คนที่สร้างสาขาและไม่เคยทำมันอีกครั้งนั่นไม่ใช่พวกเราเลย เราอาจสร้างสาขา 50-100 สาขาต่อสัปดาห์โดยไม่มีปัญหา ความท้าทายที่ยิ่งใหญ่ที่สุดคือการรวมกัน แต่เราก็ทำได้ดีเช่นกัน ฉันมักจะรวมกับกรณี Fogbugz & เช็คอินมากกว่ารากทั้งหมดของสาขา เราไม่เคยทำงานจากระยะไกลและเราไม่เคยแยกสาขาออกจากกัน หากคุณเป็นเพียงคนเดียวที่ทำงานในส่วนของฐานรหัสแล้วการผสานไปยังลำต้นจะราบรื่น หากมีคนอื่นแก้ไขโค้ดในส่วนเดียวกันการผสานอาจทำให้ยุ่งและคุณอาจต้องทำการผ่าตัด ความขัดแย้งเป็นความขัดแย้งฉันไม่เห็นว่าระบบใดสามารถทำให้ถูกต้องได้ตลอดเวลาเว้นแต่ว่าฉลาดพอที่จะเข้าใจรหัส หลังจากสร้างสาขาการชำระเงินไฟล์ 60k + ต่อไปนี้ใช้เวลาสักครู่ …

22 git  svn  mercurial  dvcs 

ฉันคิดว่าบทความนี้เป็นโมเดลการแยกสาขาที่ประสบความสำเร็จเป็นที่รู้จักกันดีในหมู่ผู้ใช้ DVCS ที่มีประสบการณ์ ฉันใช้hgเป็นส่วนใหญ่ แต่ฉันจะโต้แย้งการอภิปรายนี้เป็นสิ่งที่ดีสำหรับ DVCS ใด ๆ เวิร์กโฟลว์ปัจจุบันของเราคือผู้พัฒนาแต่ละคนลอกแบบต้นแบบธุรกรรมซื้อคืน เราเขียนโค้ดลงบน repo ในพื้นที่ของเราเองทำการทดสอบและถ้าทุกอย่างเข้ากันได้ดีกับมาสเตอร์ ดังนั้นเราจึงต้องการติดตั้งเซิร์ฟเวอร์ CI เช่น Jenkins และปรับปรุงขั้นตอนการทำงานของเราด้วยระบบการจัดเตรียมในอนาคต ส่วนจริง แบบจำลองดังกล่าวข้างต้นใช้งานได้ดี แต่กิ่งสามารถทำลาย CI ได้ สาขาฟีเจอร์ควรซิงค์กับจุดเริ่มต้น (ตามบทความมันจะเป็นdevelopmentสาขา) เพื่อทำให้ CI และการผสานราบรื่นใช่ไหม? Say Alice และ Bob กำลังทำงานกับคุณสมบัติสองอย่าง แต่อลิซเสร็จในวันรุ่งขึ้น คุณสมบัติของ Bob ใช้เวลาหนึ่งสัปดาห์ เมื่อถึงเวลาที่บ๊อบเสร็จสิ้นการเปลี่ยนแปลงของเขาล้าสมัย (อาจจะมีการปรับโครงสร้างใหม่ / เปลี่ยนชื่อคลาสบางส่วน) ทางออกหนึ่งคือนักพัฒนาทุกเช้าต้องดึงmaster/originเพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่ หากอลิซส่งมอบบ๊อบควรดึงและรวมเข้าไปในพื้นที่ทำงานของเขาเพื่อให้ฟีเจอร์สาขาของเขาทันสมัย นี่เป็นวิธีที่ดีหรือไม่? ควรสาขาเหล่านี้มีอยู่ใน repo หลัก (ไม่ใช่โคลนแบบโลคอลหรือไม่) ความหมายของนักพัฒนาทุกคนควรให้สิทธิพิเศษแก่ repo หลักใน …

18 git  continuous-integration  mercurial  dvcs  branching 

โดยทั่วไปเราใช้ Perforce และ SmartBear's Code Collaborator ที่Big Corpและตอนนี้เรากำลังจะใช้ Mercurial สำหรับบางโครงการ การทำงานร่วมกันของรหัสสนับสนุน Mercurial (เรากำลังใช้รุ่น 5) และฉันกำลังพยายามที่จะกำหนดเวลาที่ดีที่สุด (ในระหว่างกระบวนการส่ง / ส่งเซิร์ฟเวอร์) เป็นเวลาที่ดีที่สุด / มีประสิทธิภาพสำหรับการตรวจสอบรหัส ขอบคุณ

18 code-reviews  mercurial 

ฉันยังเป็นผู้ใช้โค่นล้มคนหนึ่งที่พยายามให้ความรู้แก่ตัวเองอีกครั้งในการควบคุมเวอร์ชันแบบกระจาย เมื่อใช้การโค่นล้มฉันเป็นแฟนตัวยงของวิธีการย่อยโครงการและกับอดีตนายจ้างส่วนใหญ่ของฉันเราจะจัดโครงสร้างสาขาที่เก็บของเรา แท็ก & ลำต้นดังนี้: branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk ภายในต้นไม้ต้นกำเนิดจริงเราจะใช้โครงสร้างคล้ายกันดังต่อไปนี้ (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | …

16 mercurial  organization  continuous-integration  svn  configuration-management