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

SVN ย่อมาจาก "Subversion" และเป็นระบบควบคุมเวอร์ชันโอเพ่นซอร์ส

5
เป็นวิธีที่ดีที่สุดในการตรวจสอบรหัสก่อนที่จะมุ่งมั่นที่ลำต้นคืออะไร? (SVN)
เป็นวิธีที่ดีที่สุดในการตรวจสอบรหัสก่อนที่จะมุ่งมั่นที่ลำต้น SVN คืออะไร? แนวคิดหนึ่งที่ฉันคิดคือการให้นักพัฒนาส่งรหัสของเขาไปที่สาขาแล้วทบทวนรหัสของเขาในขณะที่รวมการแก้ไขสาขาเข้ากับลำต้น นี่เป็นวิธีปฏิบัติที่ดีหรือไม่? ถ้าไม่สามารถทำอะไรได้อีกเพื่อตรวจสอบรหัสก่อนที่จะมุ่งมั่นที่ลำต้น?

5
รอบการเปิดตัวของ บริษัท แปลก: ไปควบคุมแหล่งที่มากระจาย
ขออภัยเกี่ยวกับโพสต์ที่ยาวนานนี้ แต่ฉันคิดว่ามันคุ้มค่า ฉันเพิ่งเริ่มต้นด้วยร้าน. NET ขนาดเล็กที่ทำงานค่อนข้างแตกต่างจากที่อื่น ๆ ที่ฉันเคยทำงาน ซอฟท์แวร์ที่เขียนตรงนี้ไม่ได้อยู่ในตำแหน่งก่อนหน้าใด ๆ ของฉันตรงที่มีลูกค้าหลายรายและไม่ใช่ลูกค้าทุกคนที่จะได้รับซอฟต์แวร์รุ่นล่าสุดพร้อมกัน ด้วยเหตุนี้จึงไม่มี "เวอร์ชันการผลิตปัจจุบัน" เมื่อลูกค้าได้รับการอัปเดตพวกเขายังได้รับคุณสมบัติทั้งหมดที่เพิ่มเข้ามาในซอฟต์แวร์ตั้งแต่การอัปเดตครั้งล่าสุดซึ่งอาจเป็นเวลานานแล้ว ซอฟต์แวร์สามารถกำหนดค่าได้อย่างมากและสามารถเปิดและปิดคุณสมบัติ: เรียกว่า "สลับคุณสมบัติ" วัฏจักรการวางจำหน่ายของที่นี่แน่นมากจริงๆแล้วมันไม่ได้อยู่ในกำหนดเวลา: เมื่อคุณสมบัติเสร็จสมบูรณ์ซอฟต์แวร์จะถูกปรับใช้กับลูกค้าที่เกี่ยวข้อง ทีมเมื่อปีที่แล้วย้ายจาก Visual Source Safe ไปยัง Team Foundation Server ปัญหาคือพวกเขายังคงใช้ TFS ราวกับว่ามันเป็น VSS และบังคับใช้ Checkout ล็อคในสาขารหัสเดียว เมื่อใดก็ตามที่การแก้ไขข้อผิดพลาดถูกนำออกสู่สนาม (แม้กระทั่งสำหรับลูกค้าเดี่ยว) พวกเขาเพียงแค่สร้างสิ่งที่อยู่ใน TFS ทดสอบข้อผิดพลาดได้รับการแก้ไขและปรับใช้ให้กับลูกค้า! (ตัวเองมาจากพื้นหลังของซอฟต์แวร์ยาและอุปกรณ์การแพทย์ซึ่งไม่น่าเชื่อเลย!) ผลที่ได้คือรหัส dev ที่อบออกมาครึ่งหนึ่งถูกนำไปผลิตโดยไม่ต้องมีการทดสอบ บั๊กมักจะลื่นไถลไปสู่รุ่นวางจำหน่าย แต่บ่อยครั้งที่ลูกค้าที่เพิ่งได้รับบิลด์จะไม่เห็นบั๊กเหล่านี้หากพวกเขาไม่ได้ใช้คุณสมบัติที่บั๊กนั้นอยู่ผู้อำนวยการรู้ว่านี่เป็นปัญหาเพราะ บริษัท เริ่มเติบโต ทันใดนั้นมีลูกค้ารายใหญ่บางรายเข้ามาและมีลูกค้าจำนวนน้อยกว่า ฉันถูกขอให้ดูที่ตัวเลือกการควบคุมแหล่งที่มาเพื่อกำจัดการปรับใช้ buggy หรือรหัสที่ยังไม่เสร็จ …

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

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

3
คำนวณค่าใช้จ่ายของรหัสที่ไม่ดี
ฉันกำลังมองหาข้อโต้แย้งเพื่อโน้มน้าวให้ฝ่ายบริหารลงทุนในความพยายามในการปรับโครงสร้างใหม่ เราบันทึกการทำงานโดยใช้ Jira และเชื่อมโยงทุก svn-commit กับการเรียก jira ความคิดของฉันคือการทำต่อไปนี้: ตรวจดูพื้นที่ของรหัสด้วยตนเองซึ่งมีการใช้งานที่แย่มาก แต่มักจะใช้: ทั้งจาก User-POV และ Developer-POV (แก้ไขข้อผิดพลาด) รับ svn-commits ซึ่งมี JIRA-Issues กรองปัญหาตามเกณฑ์บางอย่าง (ประเภทปัญหารุ่น prio ฯลฯ ... ) คำนวณเวลา / ความพยายามที่ใช้กับข้อบกพร่องเหล่านี้ ประเมินความพยายามและความเสี่ยงของการปรับโครงสร้างใหม่ แสดงตัวเลขและขอความพยายามแก้ไข คุณคิดยังไงกับสิ่งนี้? การวัดเช่นนี้จะมีประโยชน์และ / หรือน่าเชื่อถือไหม ข้อดีข้อเสียคืออะไร

2
เวิร์กโฟลว์แก้ไขสิ่งที่ไม่ได้อยู่ในงานปัจจุบันของคุณ
โดยปกติเมื่อฉันเขียนโปรแกรมฉันมีงานที่ชัดเจนก่อนหน้าฉัน แต่พบสิ่งที่น่ารำคาญที่ฉันต้องการทำความสะอาดเมื่อฉันไป ที่นี่ฉันเห็นสามตัวเลือก: ทำในภายหลัง (อาจลืม / ต้องใช้เวลาในการเพิ่มตั๋ว) ทำทันทีและส่งมอบงานของฉันในปัจจุบัน (ไม่ชัดเจน) ทำทันทีและกระทำแยกต่างหาก (ต้องค้นหาอาจทำผิดพลาดและไปที่ตัวเลือก # 2 โดยไม่ได้ตั้งใจ) นี่อาจเป็นพื้นฐานค่อนข้าง แต่มีวิธีใดบ้างที่จะหลีกเลี่ยงสิ่งนี้โดยใช้ svn / git / other?

2
มีความแตกต่างระหว่างการผสานใน svn เมื่อเปรียบเทียบกับ git หรือ mercurial หรือไม่?
จากความเข้าใจของฉัน SVN คือ 'ง่ายต่อการแตกสาขา ยากที่จะรวม ' ทำไมถึงเป็นอย่างนั้น? มีวิธีแตกต่างกันอย่างไร?
12 git  svn  mercurial  dvcs 

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

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

2
ความไม่สะดวกเกี่ยวกับการรวมใน SVN ก่อนหน้า v1.5 ล้าสมัยแล้วในขณะนี้หากไม่มีข้อมูลเมตาอีกต่อไป
ฉันเริ่มต้นกับ SVN และหลายแหล่งกล่าวว่าการรวมกันเป็นเรื่องยากมากใน SVN เมื่อเทียบกับเครื่องมือ DVCS คำถามล่าสุดที่ฉันสามารถหาที่นี่ใน SE มีจาก 2012 บางครั้งมีการกล่าวถึงเหตุผลที่ SVN ก่อนหน้า v1.5 ไม่มีข้อมูลเมตา แต่ SVN อยู่ในรุ่น 1.8.9 ในขณะนี้ ระบุว่า SVN นั้นเป็นผู้ใหญ่มากกว่า v1.5 และโดยเฉพาะอย่างยิ่งความจริงที่ว่าเราไม่ได้ใช้ SVN 1.5 ดังนั้นเราจึงไม่ต้องทนทุกข์ทรมานจากการขาดข้อมูลเมตาที่กล่าวถึง - ยังมีความถูกต้องมากในการโต้แย้งกับ SVN ฉันเข้าใจว่า DVCS มีวิธีที่แตกต่างอย่างสิ้นเชิงซึ่งมักเป็นที่ต้องการมากกว่า แต่สำหรับผู้ที่ "ต้อง" ues SVN ไม่ว่าด้วยเหตุผลใดก็ตามการรวมกันไม่ใช่ "นรก" จริง ๆ อีกแล้วใช่ไหม

4
เป็นที่ยอมรับหรือไม่ที่จะปรับใช้เว็บแอปกับการผลิตโดยตรงจาก SVN
คำถาม มีเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้ SVN ในการปรับใช้การผลิตหรือนี่เป็นเพียงกรณีของการตั้งค่าส่วนตัวและไม่มีกรณีจริงต่อ SVN หรือไม่? พื้นหลัง สถานที่ทำงานของฉันมีวัฒนธรรมของการติดแท็กใน SVN และจากนั้นปรับใช้การวางจำหน่ายเหล่านั้นโดยตรงกับเว็บเซิร์ฟเวอร์ต่างๆที่ใช้svn coหรือsvn switchรวมถึงการผลิตโดยตรง ฉันเองมีปัญหากับสิ่งนี้เนื่องจากฉันเชื่อว่าหากไม่ได้ใช้สคริปต์บิลด์หรือปรับใช้หรือบางรูปแบบหรือการปรับใช้อัตโนมัติคุณจะสูญเสียการตั้งค่าสภาพแวดล้อมการรวมเนื่องจากไม่มีเอกสาร อย่างไรก็ตามยิ่งไปกว่านั้นฉันมีความรู้สึกว่าอาจมีอันตรายซ่อนเร้นในการทำสิ่งที่ถูกมองข้ามบางสิ่งที่ยังไม่ได้ไปด้านหลังหัวน่าเกลียดของมัน ฉันได้นำข้อกังวลของฉันไปใช้กับเจ้าหน้าที่ปฏิบัติงานที่รับผิดชอบในการปรับใช้โค้ดให้เข้ากับสภาพแวดล้อมต่างๆของเรา (การจัดเตรียมการเตรียมการการผลิต) ฯลฯ ข้อโต้แย้งของพวกเขาค่อนข้างมากว่ามันใช้งานได้ค่อนข้างดี แก้ไข: สิ่งที่ฉันหมายถึงเกี่ยวกับการสร้างและปรับใช้: ตัวอย่างเช่นหากผู้พัฒนาต้องการเพิ่มการตั้งค่า web.config สำหรับสภาพแวดล้อมเฉพาะ โดยทั่วไปแล้ว Web.config จะไม่ถูกเก็บไว้ใน svn ดังนั้นไฟล์เหล่านี้จะถูกอัปเดตด้วยตนเองโดยไม่มีสคริปต์การสร้างอัตโนมัติในรูปแบบใด ๆ ดังนั้นหากพวกเขาหายไปหรือ OPS ลืมเพิ่มเขตข้อมูลลงใน web.config สำหรับรุ่นแล้วคุณมีปัญหา บิลด์สคริปต์ที่บอกว่าใช้ XMLPoke เพื่อสร้าง web.config ที่เหมาะสมสำหรับสภาพแวดล้อมเฉพาะนั้นเหมาะสมที่สุดเมื่อคุณมีสคริปต์เวอร์ชันที่สามารถบันทึกการเปลี่ยนแปลงทั้งหมดที่จำเป็นสำหรับแต่ละสภาพแวดล้อมของคุณ วิธีสร้างและปรับใช้ปัจจุบัน สำหรับโครงการที่สงสัยว่าผู้พัฒนาสร้างการเผยแพร่ด้วยตนเองโครงการอื่น ๆ จะมีขั้นตอนการสร้างอัตโนมัติด้วย NANT หรือ MSBuild ซึ่งก็โอเค การย้ายฐานข้อมูลสำหรับโครงการส่วนใหญ่ผ่านสคริปต์ DB หรือสคริปต์การย้ายข้อมูล …

1
อุปสรรคในการใช้ Git Flow ในการโค่นล้ม
ทีมของฉันในที่ทำงานกำลังเริ่มโครงการใหม่โดยใช้การโค่นล้มเป็น VCS ของเรา (คุณอาจพิจารณาชุดนี้เป็นหินสำหรับวัตถุประสงค์ของคำถามนี้) เรายังอยู่ในช่วงเริ่มต้นของโครงการและกำลังพยายามเห็นด้วยกับรูปแบบการแตกแขนง โครงการก่อนหน้าของเรานั้นใช้โมเดลรุ่นที่ไม่ได้มาตรฐานซึ่งนำไปสู่ปัญหาเมื่อจัดการ hot-fix และ patch ไปยังรุ่นที่มีอยู่ ฉันได้พบรุ่นแขนงที่แตกต่างกันจะมีความซับซ้อนมากกว่า แต่รุ่นหนึ่งที่ฉันไม่เข้าใจธรรมอย่างชัดเจนคือการไหลของคอมไพล์ ฉันอยากรู้ว่ายาก / ไม่พึงประสงค์มันจะใช้รูปแบบของการเปลี่ยนแปลงในการโค่นล้ม เห็นได้ชัดว่าจะมีความแตกต่างในแง่ของคนที่ทำงานร่วมกันในสาขา สาขาคุณลักษณะจะต้องมีการรวมศูนย์แทนที่จะ จำกัด อยู่เฉพาะที่เก็บในท้องที่ แต่แนวคิดอื่น ๆ ของแบบจำลองควรจะทำซ้ำได้ในการโค่นล้มเมื่อฉันเข้าใจ อะไรคือข้อเสียหรือความท้าทายในแนวทางนี้ สิ่งที่ฉันได้ยินคือใน SVN "การรวมมีราคาแพง" เมื่อเปรียบเทียบกับ Git แต่ฉันไม่ชัดเจนเกี่ยวกับสิ่งนี้ในทางปฏิบัติหรือว่ามันจะมีผลต่อความสามารถของเราในการใช้กระแส git เหมือนแบบจำลองกิ่ง สิ่งที่จะเป็นข้อกังวลที่ใหญ่ที่สุดกับวิธีนี้ มีวิธีการที่ชัดเจนในทำนองเดียวกันที่เป็นธรรมชาติมากขึ้นในการโค่นล้ม?
10 svn  branching  gitflow 

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

2
คุณควรรำคาญกับสาขา SVN หรือไม่ถ้าคุณมีสาขาเดียว?
หากเราทำงานกับสาขาเดียวในการโค่นล้มเราควรจะใส่ใจด้วยหรือไม่? เราไม่สามารถทำงานบนลำตัวเพื่อเร่งความเร็วของสิ่งต่างๆได้หรือไม่ นี่คือวิธีที่เราพัฒนาด้วยการโค่นล้ม: มีลำต้นเป็น เราสร้างสาขาการพัฒนาใหม่ เราพัฒนาคุณสมบัติใหม่ในสาขานั้น เมื่อคุณสมบัติเสร็จสิ้นจะรวมอยู่ในลำต้นสาขาจะถูกลบและสาขาการพัฒนาใหม่จะทำจากลำต้น เมื่อเราต้องการที่จะปล่อยให้การผลิตเราทำแท็กจากลำตัว การแก้ไขข้อบกพร่องจะทำในสาขาจากแท็กนั้น แก้ไขข้อผิดพลาดนี้จะรวมอยู่ในลำตัว นี่คือเหตุผลที่เราสร้างสาขาการพัฒนาใหม่หลังจากคุณสมบัติเสร็จสิ้น ด้วยวิธีนี้การแก้ไขข้อบกพร่องจะรวมอยู่ในรหัสใหม่ของเราในไม่ช้า ด้านล่างเป็นแผนภาพซึ่งควรชี้แจง: ตอนนี้มีความรู้สึกว่านี่ไม่ใช่วิธีการทำงานที่มีประสิทธิภาพที่สุด เราสร้างในพื้นที่ก่อนที่จะส่งมอบซึ่งใช้เวลาประมาณ 5-10 นาที คุณสามารถเข้าใจว่านี่เป็นประสบการณ์ที่ค่อนข้างรอเวลานาน แนวคิดของสาขาการพัฒนาคือลำตัวพร้อมปล่อยเสมอ แต่สิ่งนี้ไม่เป็นความจริงในสถานการณ์ของเราอีกต่อไป บางครั้งคุณลักษณะเกือบจะพร้อมแล้วและนักพัฒนาบางคนจะเริ่มเขียนโค้ดคุณลักษณะถัดไปแล้ว (ไม่เช่นนั้นพวกเขาจะนั่งรอผู้พัฒนาหนึ่งหรือสองคนเพื่อรวมและผสาน) จากนั้นเมื่อคุณสมบัติ 1 เสร็จสิ้นจะถูกรวมเข้ากับลำต้น แต่มีคุณสมบัติบางอย่างรวมอยู่ด้วย 2 ดังนั้นเราควรจะรำคาญกับสาขาการพัฒนาเพราะเรามีเพียงสาขาเดียว? ฉันได้อ่านเกี่ยวกับการพัฒนาแบบอิงลำตัวและการแยกสาขา แต่บทความส่วนใหญ่ที่ฉันได้พบมุ่งเน้นไปที่ส่วนย่อยโดยการย่อ ฉันได้รับความประทับใจสำหรับการเปลี่ยนแปลงครั้งใหญ่ที่จะครอบคลุมการเผยแพร่หลายรายการ นี่ไม่ใช่ปัญหาที่เรามี คุณคิดอย่างไร? เราสามารถทำงานบนลำตัวได้หรือไม่? สถานการณ์เลวร้ายที่สุดคือ (ฉันคิดว่า) ว่าเราจะต้องสร้างแท็กจากลำตัวและเลือกเชอร์รี่ที่เราต้องการเพราะคอมมิท / คุณสมบัติบางอย่างยังไม่พร้อมใช้งาน
10 svn  branching  tagging 

4
แนวปฏิบัติที่เหมาะสมกับซอร์สโค้ดการแยกและวงจรชีวิตของแอปพลิเคชัน
เราเป็นร้าน ISV ขนาดเล็กและเรามักจะจัดส่งผลิตภัณฑ์รุ่นใหม่ทุกเดือน เราใช้การโค่นล้มเป็นที่เก็บรหัสและ Visual Studio 2010 เป็น IDE ของเรา ฉันรู้ว่าผู้คนจำนวนมากกำลังสนับสนุน Mercurial และระบบควบคุมแหล่งข้อมูลแบบกระจายอื่น ๆ แต่ ณ จุดนี้ฉันไม่เห็นว่าเราจะได้ประโยชน์จากสิ่งเหล่านี้อย่างไร แต่ฉันอาจผิด ปัญหาหลักของเราคือวิธีการทำให้สาขาและลำต้นหลักตรงกัน นี่คือวิธีที่เราทำสิ่งต่าง ๆ ในวันนี้: ปล่อยเวอร์ชันใหม่ (สร้างแท็กในการโค่นล้มโดยอัตโนมัติ) ทำงานต่อในลำตัวหลักที่จะเปิดตัวในเดือนหน้า และวงจรจะทำซ้ำทุกเดือนและทำงานได้อย่างสมบูรณ์ ปัญหาเกิดขึ้นเมื่อจำเป็นต้องมีการเปิดตัวบริการด่วน เราไม่สามารถปล่อยมันจากลำต้นหลัก (2) เนื่องจากอยู่ภายใต้การพัฒนาอย่างหนักและมันไม่เสถียรพอที่จะปล่อยอย่างเร่งด่วน ในกรณีเช่นนี้เราจะทำสิ่งต่อไปนี้: สร้างสาขาจากแท็กที่เราสร้างในขั้นตอน (1) แก้ไขข้อผิดพลาด ทดสอบและปล่อย ผลักดันการเปลี่ยนแปลงกลับไปที่ลำต้นหลัก (ถ้ามี) ปัญหาที่ใหญ่ที่สุดของเราคือการรวมสองสิ่งนี้ (สาขากับหลัก) ในกรณีส่วนใหญ่เราไม่สามารถพึ่งพาการรวมอัตโนมัติได้เช่น: มีการเปลี่ยนแปลงมากมายกับลำต้นหลัก การรวมไฟล์ที่ซับซ้อน (เช่นไฟล์ Visual Studio XML เป็นต้น) ทำงานได้ไม่ดีนัก นักพัฒนา / …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.