การย้าย repo SVN หลาย GB ไปยัง Git

ปัจจุบัน บริษัท ของฉันมี Visual Studio solation ใน repo SVN ที่จัดเป็นดังนี้:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1 และ Tool2 เป็นบิลด์อิสระ (มีโซลูชันของตัวเอง) แต่สร้างไฟล์ปฏิบัติการที่ใช้ในบิลด์หลัก โฟลเดอร์ ThirdParty มีการขึ้นต่อกันทั้งหมดของโครงการรวมถึงไฟล์. lib ขนาด 100+ MB ที่รวบรวมไว้ล่วงหน้าและไลบรารี่ขนาดใหญ่เช่นบูสต์

มันสะดวกที่จะมีทุกอย่างใน SVN repo เพื่อให้นักพัฒนา (1) ต้องเช็คเอาต์เพียงครั้งเดียวและ (2) เราไม่จำเป็นต้องติดตามเวอร์ชันการพึ่งพาที่เราต้องการสำหรับบิลด์แต่ละเวอร์ชัน ในด้านพลิกมันใช้เวลาสักครู่เพื่อตรวจสอบ repo นี้

อะไรจะเป็นวิธีที่ดีที่สุดในการย้ายโครงสร้างโครงการนี้ไปคอมไพล์? สันนิษฐานว่าเป็นการดีที่สุดที่จะไม่รวม ThirdParty และเครื่องมือจาก repo หลัก แต่เราต้องการให้ ThirdParty ดาวน์โหลดได้ง่ายในขั้นตอนเดียวและเราชอบเวอร์ชัน (และเวอร์ชันไม่ตรงกันระหว่าง repo หลักและ ThirdParty / Tools จะไม่ดี)

ณ จุดนี้ฉันไม่ได้สนใจในการรักษาประวัติศาสตร์เพียงในการหาวิธีการจัดระเบียบโครงการดังกล่าว

ใช้เครื่องมือที่เหมาะสมสำหรับงาน ใน Windows นั่นหมายถึง

ใช้ NuGet สำหรับการอ้างอิงบุคคลที่สาม

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

แน่นอนคุณสามารถใช้โซลูชันที่ใช้ git (repo อื่น, submodules และอื่น ๆ ) แต่นั่นเป็นเพียงการแฮ็ก การทำในสิ่งที่ถูกต้องจะชำระให้เร็วและทำให้คุณมีระบบพิสูจน์อนาคต

แก้ไขหลังจากความคิดเห็น: วิธีที่ดีที่สุดในการใช้ NuGet คือการตั้งค่าแหล่งที่มาของ NuGet ในพื้นที่ไม่ว่าจะเป็นบนไดรฟ์ที่ใช้ร่วมกันหรือเซิร์ฟเวอร์แบบเต็ม nuget การตั้งค่าไม่ควรใช้เวลามากกว่าสองสามนาที ด้วยวิธีนี้คุณสามารถรับประกันได้ว่าแพ็คเกจทั้งหมดที่คุณต้องการจะมีให้บริการเสมอไม่ว่าจะเกิดจากที่ใด

คุณสามารถใช้submodulesสำหรับเครื่องมือ ด้วยวิธีนี้คุณสามารถเก็บไว้ในไดเรกทอรีย่อยอย่างที่คุณทำตอนนี้และใช้ repo แยกต่างหากสำหรับการกำหนดเวอร์ชัน นั่นก็หมายความว่าคุณสามารถโคลน (ชำระเงิน) เครื่องมือและพัฒนาแยกต่างหากและโครงการอื่น ๆ อาจพึ่งพา repos เหล่านั้น - และในเวอร์ชันที่เฉพาะเจาะจงและน่าเชื่อถือเช่นกัน

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

เอนทิตีที่คุณเปลี่ยนเป็นที่เก็บคอมไพล์จำเป็นต้องเป็นเอนทิตีที่คุณใช้เวอร์ชันและสาขา หากSolutionFolder/Tools/Tool1สอดคล้องกับสิ่งหนึ่งนั่นคือระดับของเอนทิตี เพราะนี่คือคอมไพล์นับถือทั้งรัฐของต้นไม้ไดเรกทอรีที่จะเป็นนิติบุคคลที่ versionable ในขณะที่มี SVN มันเป็นไปได้ (แม้ว่าจะไม่ได้เป็นความคิดที่ดี) จะมีtrunk, branchesและtagsที่ใดก็ได้ภายในต้นไม้

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

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

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

สิ่งที่ฉันเล่นด้วยคือการตั้งค่าเครื่องมือของบุคคลที่สามใน repo แยกต่างหาก จากนั้นฉันมีสคริปต์แบตช์ง่าย ๆ หนึ่งตัวอ่านไฟล์ข้อความที่มีการอ้างอิง sha1 และตรวจสอบรุ่นที่ถูกต้อง สิ่งนี้จะทำให้ฉันมีรุ่นที่สามที่แตกต่างกันสำหรับโครงการที่แตกต่างกัน ฉันได้รับแนวคิดนี้จากเครื่องมือสร้าง Facebook Buck แต่ในที่สุดนักพัฒนาหลายคนไม่ชอบใช้เครื่องมือบรรทัดคำสั่ง (ร้านค้า MS VC ที่นี่) ดังนั้นฉันจึงเลิกคิด

เหตุผลหนึ่งที่สำคัญว่าทำไมไม่ดาวน์โหลด libs บุคคลที่สามของคุณเมื่อคุณต้องการ (ใช้ NuGet) คือถ้าคุณต้องการสนับสนุนผลิตภัณฑ์ของคุณเป็นเวลานาน ในอุตสาหกรรมของฉันเราจำเป็นต้องให้การอัปเดตสำหรับเวอร์ชันเก่าที่อาศัย libs ของบุคคลที่สามเก่า เราไม่ต้องการใช้เวลามากมายในการแยกแยะว่า libs ใดที่เราสามารถอัพเกรดได้หรือไม่และเพียงแค่ใช้ libs ตามที่ใช้ในเวอร์ชันนั้น ทีนี้ลองนึกว่าคุณใช้ NuGet แล้วอ๊ะ ... เวอร์ชันล่าสุดของ lib ที่คุณต้องการคือ 3.98 แต่คุณต้อง 2.04 ..... วิธีอธิบายเจ้านายของคุณว่าคุณต้องใช้เวลา 2 เดือนในการอัพเกรดเวอร์ชั่นเก่าเพื่อให้สามารถใช้งานได้ ใช้ libs ล่าสุดเมื่อเขาคาดหวังว่าจะมีการเปลี่ยนแปลงเล็กน้อย!