คุณจัดระเบียบที่เก็บการควบคุมเวอร์ชันของคุณอย่างไร

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

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

ในการล้างคำศัพท์: โซลูชันหมายถึงผลิตภัณฑ์เดียว Project คือ Visual Studio Project (ซึ่งให้ผลลัพธ์เป็น. dll หรือ. exe ตัวเดียว)

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

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

หากคุณทำตามคำแนะนำของฉันด้านล่าง (ฉันมีมาหลายปีแล้ว) คุณจะสามารถ:

- วางแต่ละโครงการไว้ที่ใดก็ได้ในการควบคุมแหล่งที่มาตราบเท่าที่คุณรักษาโครงสร้างจากไดเรกทอรีรากของโครงการ

- สร้างแต่ละโครงการได้ทุกที่บนเครื่องใดก็ได้โดยมีความเสี่ยงขั้นต่ำและการเตรียมขั้นต่ำ

- สร้างแต่ละโครงการแบบสแตนด์อะโลนโดยสมบูรณ์ตราบเท่าที่คุณสามารถเข้าถึงการอ้างอิงไบนารี (ไดเร็กทอรี "ไลบรารี" และ "เอาต์พุต" ในเครื่อง)

- สร้างและทำงานร่วมกับโครงการใด ๆ เนื่องจากเป็นอิสระ

- สร้างและทำงานกับหลายสำเนา / เวอร์ชันของโครงการเดียวเนื่องจากเป็นอิสระ

- หลีกเลี่ยงความยุ่งเหยิงที่เก็บข้อมูลการควบคุมซอร์สของคุณด้วยไฟล์หรือไลบรารีที่สร้างขึ้น

ฉันแนะนำ (นี่คือเนื้อวัว):

1. กำหนดแต่ละโปรเจ็กต์เพื่อสร้างการส่งมอบหลักรายการเดียวเช่น. DLL, .EXE หรือ. JAR (ค่าเริ่มต้นด้วย Visual Studio)

2. จัดโครงสร้างแต่ละโครงการเป็นแผนผังไดเร็กทอรีที่มีรูทเดียว

3. สร้างสคริปต์บิลด์อัตโนมัติสำหรับแต่ละโปรเจ็กต์ในไดเร็กทอรีรูทซึ่งจะสร้างตั้งแต่เริ่มต้นโดยไม่มีการพึ่งพา IDE (แต่อย่าป้องกันไม่ให้สร้างใน IDE หากเป็นไปได้)

4. พิจารณาโครงการ nAnt สำหรับ. NET บน Windows หรือสิ่งที่คล้ายกันตามระบบปฏิบัติการของคุณแพลตฟอร์มเป้าหมาย ฯลฯ

5. ทำให้ทุกโครงการบิวด์สคริปต์อ้างอิงการอ้างอิงภายนอก (ของบุคคลที่สาม) จากไดเร็กทอรี "ไลบรารี" ที่แบ่งใช้ภายในเครื่องเดียวโดยทุกไบนารีจะระบุตามเวอร์ชัน: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.

6. ทำให้ทุกโครงการสร้างสคริปต์เผยแพร่ส่งมอบหลักในท้องถิ่นร่วมกัน "ส่งออก" ไดเรกทอรีเดียว: ,%DirOutputRoot%\ProjectA-9.10.11.12.dll%DirOutputRoot%\ProjectB-13.14.15.16.exe

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

8. อย่าให้โปรเจ็กต์อ้างอิงโปรเจ็กต์อื่นโดยตรงหรือเนื้อหาใด ๆ ของโปรเจ็กต์ - อนุญาตเฉพาะการอ้างอิงไปยังสิ่งที่ส่งมอบหลักในไดเร็กทอรี "เอาต์พุต" (ดูด้านบน)

9. ทำให้ทุกโครงการสร้างสคริปต์อ้างอิงเครื่องมือสร้างที่จำเป็นโดยเส้นทางสัมบูรณ์ที่กำหนดค่าได้และมีเวอร์ชันเต็ม: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.

10. สร้างเนื้อหาซอร์สการอ้างอิงสคริปต์บิลด์โปรเจ็กต์ทั้งหมดโดยพา ธ สัมบูรณ์ที่สัมพันธ์กับไดเร็กทอรีรูทของโปรเจ็กต์: ${project.base.dir}/src, ${project.base.dir}/tst(ไวยากรณ์แตกต่างกันไปตามเครื่องมือบิลด์)

11. มักจะต้องใช้สคริปต์สร้างโครงการเพื่ออ้างอิงทุกไฟล์หรือไดเร็กทอรีผ่านพา ธ ที่กำหนดค่าได้แน่นอน (รูทที่ไดเร็กทอรีที่ระบุโดยตัวแปรที่กำหนดค่าได้): ${project.base.dir}/some/dirsหรือ${env.Variable}/other/dir.

12. ไม่อนุญาตให้สคริปต์บิลด์โปรเจ็กต์อ้างอิงสิ่งใด ๆ ด้วยพา ธ สัมพัทธ์เช่น.\some\dirs\hereหรือ..\some\more\dirsใช้พา ธสัมบูรณ์เสมอ

13. ไม่อนุญาตให้โครงการสร้างสคริปต์อะไรอ้างอิงโดยใช้เส้นทางที่แน่นอนว่าไม่ได้มีการกำหนดค่าไดเรกทอรีรากเหมือนหรือC:\some\dirs\here\\server\share\more\stuff\there

14. สำหรับไดเร็กทอรีรูทที่กำหนดค่าได้ซึ่งอ้างอิงโดยสคริปต์การสร้างโปรเจ็กต์ให้กำหนดตัวแปรสภาพแวดล้อมที่จะใช้สำหรับการอ้างอิงเหล่านั้น

15. พยายามลดจำนวนตัวแปรสภาพแวดล้อมที่คุณต้องสร้างเพื่อกำหนดค่าแต่ละเครื่อง

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

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

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

19. ต้องใช้สคริปต์บิลด์โปรเจ็กต์แต่ละรายการเพื่อตรวจสอบไฟล์ปฏิบัติการบิวด์ของเครื่องมือสร้างที่ขึ้นต่อกันไฟล์ไลบรารีภายนอกและไฟล์ที่ส่งมอบได้ของโปรเจ็กต์ที่เกี่ยวข้องและยกเลิกด้วยข้อความที่มีความหมายหากไม่มีไฟล์เหล่านั้น

20. ต่อต้านสิ่งล่อใจในการส่งไฟล์ใด ๆ ที่สร้างขึ้นในการควบคุมแหล่งที่มา - ไม่มีการส่งมอบโครงการไม่มีแหล่งที่มาที่สร้างขึ้นไม่มีเอกสารที่สร้างขึ้นเป็นต้น

21. หากคุณใช้ IDE ให้สร้างไฟล์ควบคุมโปรเจ็กต์ใดก็ได้ที่คุณสามารถทำได้และอย่าผูกมัดไฟล์เหล่านั้นกับการควบคุมซอร์ส (ซึ่งรวมถึงไฟล์โปรเจ็กต์ Visual Studio)

22. สร้างเซิร์ฟเวอร์ที่มีสำเนาอย่างเป็นทางการของไลบรารีและเครื่องมือภายนอกทั้งหมดเพื่อคัดลอก / ติดตั้งบนเวิร์กสเตชันของนักพัฒนาและสร้างเครื่อง สำรองข้อมูลพร้อมกับที่เก็บการควบคุมแหล่งที่มาของคุณ

23. สร้างเซิร์ฟเวอร์รวมแบบต่อเนื่อง (สร้างเครื่อง) โดยไม่มีเครื่องมือในการพัฒนาใด ๆ

24. พิจารณาเครื่องมือสำหรับจัดการไลบรารีภายนอกและสิ่งที่ส่งมอบเช่น Ivy (ใช้กับ Ant)

25. อย่าใช้ Maven - มันจะทำให้คุณมีความสุขในตอนแรกและในที่สุดก็ทำให้คุณร้องไห้

โปรดทราบว่าสิ่งนี้ไม่เฉพาะเจาะจงสำหรับการโค่นล้มและส่วนใหญ่เป็นเรื่องทั่วไปสำหรับโครงการที่กำหนดเป้าหมายไปยังระบบปฏิบัติการฮาร์ดแวร์แพลตฟอร์มภาษา ฯลฯ ฉันใช้ไวยากรณ์เฉพาะของระบบปฏิบัติการและเครื่องมือเพียงเล็กน้อย แต่ใช้เพื่อภาพประกอบเท่านั้น - ฉันเชื่อว่าคุณจะแปลเป็นระบบปฏิบัติการหรือเครื่องมือที่คุณเลือก

หมายเหตุเพิ่มเติมเกี่ยวกับโซลูชัน Visual Studio: อย่าวางไว้ในการควบคุมแหล่งที่มา! ด้วยวิธีนี้คุณไม่จำเป็นต้องใช้เลยหรือคุณสามารถสร้างได้ (เช่นเดียวกับไฟล์โครงการ Visual Studio) อย่างไรก็ตามฉันคิดว่าเป็นการดีที่สุดที่จะฝากไฟล์โซลูชันไว้ให้นักพัฒนาแต่ละรายเพื่อสร้าง / ใช้ตามที่เห็นสมควร (แต่ไม่ได้เช็คอินเพื่อควบคุมแหล่งที่มา) ฉันเก็บRob.slnไฟล์ไว้บนเวิร์กสเตชันที่ใช้อ้างอิงโปรเจ็กต์ปัจจุบันของฉัน เนื่องจากโครงการของฉันเป็นแบบสแตนด์อะโลนทั้งหมดฉันจึงสามารถเพิ่ม / ลบโครงการได้ตามต้องการ (ซึ่งหมายความว่าไม่มีการอ้างอิงการอ้างอิงตามโครงการ)

โปรดอย่าใช้ Subversion externals (หรือคล้ายกันในเครื่องมืออื่น ๆ ) เนื่องจากเป็นการต่อต้านรูปแบบดังนั้นจึงไม่จำเป็น

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

@VonC: คุณไม่ต้องการทำงานกับ "ant.jar" ตลอดเวลาแทนที่จะเป็น "ant-abcdjar" หลังจากที่คุณถูกเบิร์นเมื่อสคริปต์การสร้างของคุณหยุดทำงานเนื่องจากคุณเรียกใช้ Ant รุ่นที่เข้ากันไม่ได้โดยไม่รู้ตัว โดยเฉพาะอย่างยิ่งระหว่าง Ant 1.6.5 และ 1.7.0 โดยทั่วไปคุณมักต้องการทราบว่ามีการใช้ส่วนประกอบ EVERY เวอร์ชันใดบ้างรวมถึงแพลตฟอร์มของคุณ (Java ABCD) และเครื่องมือสร้างของคุณ (Ant EFGH) มิฉะนั้นคุณจะพบข้อบกพร่องในที่สุดและปัญหาใหญ่ครั้งแรกของคุณจะเป็นการติดตามว่าส่วนประกอบต่างๆของคุณเกี่ยวข้องกับเวอร์ชันใด เป็นการดีกว่าที่จะแก้ปัญหานั้นต่อหน้า

ฉันเชื่อว่าPragmatic Version Control โดยใช้ Subversionมีทุกสิ่งที่คุณต้องการเพื่อจัดระเบียบที่เก็บของคุณ

เราได้ตั้งค่าของเราให้ตรงกับที่คุณโพสต์ไว้เกือบทั้งหมด เราใช้รูปแบบทั่วไป:

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

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

เหตุใดจึงมีทั้งหมดในที่เก็บเดียว ทำไมไม่เพียงแค่มีที่เก็บแยกต่างหากสำหรับแต่ละโครงการ (ฉันหมายถึง "โซลูชัน")

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

และคุณวางแผนที่จะใส่ลงในที่เก็บขนาดใหญ่นี้กี่โครงการ? 2? 3? 10? 100?

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

แล้วความยุ่งเหยิงของหมายเลขเวอร์ชันทั้งหมดนั้นล่ะ? หมายเลขเวอร์ชันของโครงการหนึ่งจะเป็นเช่น 2, 10, 11 ในขณะที่อีกโครงการหนึ่งจะเป็นเช่น 1, 3, 4, 5, 6, 7, 8, 9, 12 ...

บางทีฉันอาจจะโง่ แต่ฉันชอบหนึ่งโครงการต่อที่เก็บ

ฉันคิดว่าข้อเสียเปรียบหลักของโครงสร้างที่เสนอคือโครงการที่ใช้ร่วมกันจะได้รับการปรับปรุงเวอร์ชันด้วยโซลูชันแรกที่เพิ่มเข้ามาเท่านั้น (เว้นแต่ svn: externals นั้นน่าสนใจกว่าที่ฉันจินตนาการไว้) ตัวอย่างเช่นเมื่อคุณสร้างสาขาสำหรับ Solution2 รุ่นแรก Project1 จะไม่ถูกแยกเนื่องจากอยู่ใน Solution1 หากคุณต้องการสร้างจากสาขานั้นในเวลาต่อมา (รุ่น QFE) จะใช้เวอร์ชันล่าสุดของ Project1 แทนที่จะเป็นเวอร์ชันของ Project1 ในช่วงเวลาของสาขา

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

ในการเพิ่มปัญหาพา ธ สัมพัทธ์:

ฉันไม่แน่ใจว่าเป็นปัญหา:
เพียงแค่ชำระเงิน Solution1 / trunk ภายใต้ไดเร็กทอรีชื่อ "Solution1" ditto สำหรับ Solution2: เป้าหมายของ 'ไดเรกทอรี' ที่แสดงถึงสาขาจริงจะไม่ปรากฏให้เห็นเมื่อนำเข้าสู่พื้นที่ทำงาน ดังนั้นเส้นทางสัมพัทธ์จึงเป็นไปได้ระหว่าง 'Solution1' (จริงๆแล้ว 'Solution1 / trunk') และ 'Solution2' (Solution2 / trunk)

RE: เส้นทางสัมพัทธ์และปัญหาไฟล์ที่แชร์ -

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

เรายังคงดำเนินการอยู่และฉันมีความพยายาม 3 อย่าง (ไคลเอนต์ที่แตกต่างกัน) ที่ฉันต้องแก้ไขในตอนนี้เนื่องจากฉันเข้าควบคุมการตั้งค่าการควบคุมเวอร์ชันที่ไม่มีอยู่จริงหรือไม่ดี

ฉันมีเลย์เอาต์ที่คล้ายกัน แต่ลำต้นกิ่งก้านของฉันอยู่ด้านบนสุด ดังนั้น: / trunk / main, / trunk / utils, / branch / release / ฯลฯ

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