Memindahkan repo SVN multi-GB ke Git


13

Saat ini perusahaan saya memiliki solusi Visual Studio dalam repo SVN yang diatur sebagai berikut:

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

Tool1 dan Tool2 dibuat secara mandiri (memiliki solusi sendiri), tetapi menghasilkan file yang dapat dieksekusi yang digunakan dalam bangunan utama. Folder ThirdParty berisi semua dependensi untuk proyek, termasuk beberapa file .lib 100+ MB yang telah dikompilasi sebelumnya dan perpustakaan besar seperti boost.

Sangat mudah untuk memiliki semuanya dalam satu repo SVN sehingga (1) pengembang hanya perlu melakukan satu check-out, dan (2) kita tidak perlu melacak versi dependensi yang kita butuhkan untuk setiap versi build. Di sisi lain, perlu beberapa saat untuk memeriksa repo ini.

Apa cara terbaik untuk memindahkan struktur proyek ini ke git? Agaknya yang terbaik adalah mengecualikan ThirdParty dan mungkin Tools dari repo utama, tetapi kami ingin menjaga ThirdParty mudah diunduh dalam satu langkah, dan kami menyukainya versi (dan ketidakcocokan versi antara repo utama dan ThirdParty / Tools akan buruk).

Pada titik ini saya tidak tertarik melestarikan sejarah, hanya mencari tahu bagaimana mengatur proyek seperti itu.


Apakah ukuran di atas ukuran dalam repo, termasuk riwayat, atau apakah itu ukuran copy pekerjaan lokal?
Doc Brown

1
@DocBrown hanya copy pekerjaan lokal, tidak termasuk riwayat.
ikh

Jawaban:


10

Gunakan alat yang tepat untuk pekerjaan itu. Di Windows, itu artinya

Gunakan NuGet untuk dependensi pihak ketiga

Dengan begitu, Anda menjaga dependensi pihak ketiga dalam versi berversi, tetapi Anda tidak akan mengasapi repositori Anda dengan hal-hal yang tidak dibutuhkan. Checkout lebih cepat, dan proyek diatur sebagaimana mestinya. Anda dapat mengaktifkan opsi di Visual Studio sehingga selalu mengunduh semua dependensi secara otomatis.

Tentu saja Anda dapat menggunakan solusi yang hanya menggunakan git (repo lain, submodul dll), tapi itu hanya peretasan. Melakukannya dengan cara yang benar akan membuahkan hasil dengan cepat, dan meninggalkan Anda dengan sistem bukti masa depan.

Edit setelah komentar: Cara terbaik untuk menggunakan NuGet adalah dengan mengatur sumber NuGet lokal, baik pada drive bersama, atau server nuget penuh. Pengaturan seharusnya tidak memakan waktu lebih dari beberapa menit. Dengan begitu, Anda dapat menjamin bahwa semua paket yang Anda butuhkan selalu tersedia, di mana pun mereka berasal.


Apakah NuGet mendukung perintah yang dibangun? Saya selalu mencari bangunan portabel yang bisa saya buat Jenkins untuk membangun dan menguji saya. Apakah NuGet mendukung server CI seperti Jenkins?
buka sepenuhnya

Satu pemikiran lagi, berapa lama Anda perlu mendukung produk Anda? Jika Anda perlu memberikan dukungan untuk waktu yang sangat lama, saya tidak akan mengandalkan versi lib pihak ketiga yang benar untuk tersedia di NuGet. Anda mungkin mendapatkan masalah yang sangat besar dengan mengandalkan alat seperti NuGet untuk mendapatkan kombinasi alat pihak ketiga yang benar, bahkan dalam 2-3 tahun dari sekarang.
buka sepenuhnya

3
@uncletall: ya, NuGet memiliki antarmuka baris perintah yang lengkap. Dan idenya adalah untuk mengatur repositori NuGet lokal, yang mungkin hanya folder pada jaringan berbagi (disebut "feed", docs.nuget.org/docs/creating-packages/… )
Doc Brown

Ya, saya berasumsi tentu saja bahwa Anda menggunakan cermin lokal. Saya akan memperbarui jawabannya.
Wilbert

2
@ikh cukup sederhana dan mudah untuk membangun paket nuget untuk dependensi eksternal. Saya membutuhkan sekitar setengah hari untuk mengemas 9 dependensi dengan 50 dll, karena belum pernah melakukannya sebelumnya.
Wilbert

5

Anda dapat menggunakan submodula untuk alat-alat tersebut. Dengan begitu Anda bisa menyimpannya dalam subdirektori seperti yang Anda lakukan sekarang, dan menggunakan repo yang terpisah untuk membuat versi mereka. Itu juga berarti Anda dapat mengkloning (checkout) alat-alat itu dan mengembangkannya secara terpisah, dan bahwa proyek-proyek lain dapat mengandalkan repo-repo itu - dan pada versi-versi yang spesifik dan dapat diterima juga.

Anda juga bisa menggunakan submodul untuk pustaka pihak ketiga, tetapi jika memungkinkan saya akan merekomendasikan menggunakan manajer dependensi untuk itu.


4

Entitas yang Anda ubah menjadi repositori git tentu saja entitas yang Anda versi dan cabang; jika SolutionFolder/Tools/Tool1sesuai dengan satu hal seperti itu, itulah tingkat entitas. Ini karena git menganggap seluruh status pohon direktori sebagai entitas yang dapat versi, sedangkan dengan svn dimungkinkan (bahkan jika bukan ide yang baik) untuk memiliki trunk, branchesdan di tagsmana saja di dalam pohon.

Artefak yang diturunkan tidak boleh disimpan di repositori, atau perpustakaan eksternal. Ada cara yang lebih baik untuk mengatasinya. (Jika Anda bekerja dengan Java, pertimbangkan untuk menggunakan repositori Maven pribadi; itu relatif mudah digunakan, dan terintegrasi dengan baik dengan banyak hal lain.)

Jika Anda terbiasa dengan alur kerja yang memiliki segalanya dalam satu repo untuk kemudahan checkout, pertimbangkan memiliki skrip yang mengatur semuanya.


Apa saja opsi untuk mengelola perpustakaan eksternal? Kami bekerja pada Visual Studio dengan C ++ dan C #, jadi Maven tidak terlihat cocok. Masalah utama di sini adalah bahwa memiliki ThirdPartyfolder di repo sangat nyaman, dan sulit untuk datang dengan alternatif yang baik.
ikh

2
@ikh: Dalam lingkungan Visual Studio, Anda biasanya akan menggunakan Nuget untuk ini, docs.nuget.org , yang sudah termasuk dalam VS 2012 dan versi yang lebih baru.
Doc Brown

2

Sejujurnya saya tidak akan mengubah apa pun di pengaturan Anda. Itulah tepatnya yang sedang kita lakukan sekarang. Saya bermain-main dengan menyiapkan repositori git terpisah untuk menangani lib pihak ketiga yang kami gunakan, tetapi saya tidak berpikir itu berbobot dengan biaya portabilitas. Sekarang setiap pengembang dapat checkout dan memulai tanpa harus melakukan langkah-langkah pengaturan manual. Dan saya pun membangun server / slave dapat membangun proyek. Kecuali Anda memiliki multi repo berbagi alat pihak ketiga saya hanya akan tetap dengan pengaturan Anda saat ini.

Apa yang saya lakukan bermain-main adalah menyiapkan alat pihak ketiga dalam repo terpisah. Lalu aku punya satu skrip batch sederhana membaca file teks dengan sha1 ref dan checkout versi yang benar. Ini akan memungkinkan saya untuk memiliki versi pihak ketiga yang berbeda untuk proyek yang berbeda. Saya mendapat ide ini dari alat pembuatan Facebook Buck. Tetapi pada akhirnya banyak pengembang tidak suka menggunakan alat baris perintah (toko MS VC di sini) jadi saya menyerah pada ide.

Salah satu alasan utama mengapa tidak mengunduh lib pihak ketiga Anda saat Anda membutuhkannya (menggunakan NuGet) adalah jika Anda perlu mendukung produk Anda untuk waktu yang lama. Di industri saya, kami terkadang harus menyediakan pembaruan untuk versi lama yang bergantung pada lib pihak ketiga yang lama. Kami tidak ingin menghabiskan banyak waktu memilah lib mana yang dapat kami tingkatkan atau tidak dan hanya menggunakan lib seperti yang digunakan dalam versi itu. Sekarang bayangkan Anda menggunakan NuGet, oops ... versi terbaru dari lib yang Anda butuhkan adalah 3,98 tetapi Anda perlu 2,04 ..... bagaimana menjelaskan kepada atasan Anda bahwa Anda harus menghabiskan 2 bulan untuk meningkatkan versi lama agar dapat meningkatkan versi lama untuk dapat untuk menggunakan lib terbaru ketika dia mengharapkan perubahan kecil!


3
Meskipun saya memberi Anda +1, karena "biarkan semuanya apa adanya" adalah solusi pragmatis, saya pikir "beberapa repo" mungkin bukan satu-satunya masalah. DVCS seperti Git mendorong untuk memiliki banyak cabang lokal, dan di setiap cabang, salinan lokal lengkap semuanya. Jadi ini dapat menyebabkan memiliki perpustakaan pihak ketiga besar yang sama (biasanya versi yang sama!) Beberapa kali sebagai salinan lokal. Ini mungkin layak dalam beberapa situasi, dalam situasi lain saya dapat membayangkan bahwa ini akan berdampak negatif pada kinerja percabangan dan penggabungan.
Doc Brown

Sejauh yang saya tahu, cabang adalah operasi yang sangat murah di Git yang hanya akan membuat pointer dan mengambil ruang hampir nol.
buka sepenuhnya


Kecuali saya kehilangan sesuatu, cabang "bebas" di Git. Saya baru saja memeriksa .git / refs / head dan semua cabang adalah file teks 1KB, .git / logs / refs / head berisi log di mana yang terbesar adalah 11KB untuk master .. Struktur proyek normal saya adalah sekitar 500MB dalam kode, lib pihak ketiga dan alat-alat lainnya. Saya sangat senang menerima pukulan 1KB karena membuat cabang
lengkap

1
@MichaelT: percabangan itu sendiri gratis, tentu saja, tetapi saya berbicara tentang situasi di mana Anda memiliki banyak copy pekerjaan dari berbagai cabang di workstation lokal Anda secara paralel. Dan jika Anda memeriksa komentar di bawah pertanyaan asli, OP merujuk ke 3GB alat pihak ketiga sebagai ukuran copy pekerjaan.
Doc Brown
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.