Çok GB'lı bir SVN deposunu Git'e taşıma

Şu anda şirketimin SVN deposunda aşağıdaki gibi organize edilmiş bir Visual Studio çözümü var:

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

Araç1 ve Araç2 bağımsız olarak oluşturulur (kendi çözümlerine sahiptir), ancak ana yapıda kullanılan yürütülebilir dosyalar üretir. ThirdParty klasörü, bazı önceden derlenmiş 100+ MB .lib dosyaları ve boost gibi büyük kütüphaneler dahil olmak üzere proje için tüm bağımlılıkları içerir.

Hepsini bir SVN deposunda bulundurmak uygundur, böylece (1) geliştiricinin yalnızca bir çıkış yapması gerekir ve (2) yapının her sürümü için hangi bağımlılık sürümlerine ihtiyacımız olduğunu takip etmemiz gerekmez. Kapak tarafında, bu repoya bakmak biraz zaman alıyor.

Bu proje yapısını git'e taşımanın en iyi yolu ne olurdu? Muhtemelen ThirdParty ve muhtemelen Tools'u ana repodan hariç tutmak en iyisidir, ancak ThirdParty'yi bir adımda kolayca indirilebilir tutmak istiyoruz ve sürümlendirilmesini beğendik (ve ana repo ile ThirdParty / Tools arasındaki sürüm uyumsuzlukları kötü olurdu).

Bu noktada, tarihi korumakla değil, sadece böyle bir projenin nasıl organize edileceğini bulmakla ilgileniyorum.

İş için uygun aleti kullanın. Windows'da bu,

Üçüncü taraf bağımlılıkları için NuGet kullanma

Bu şekilde, üçüncü taraf bağımlılıkları sürümlü bir şekilde tutarsınız, ancak deponuzu gereksiz şeyler ile şişirmezsiniz. Kasalar çok daha hızlıdır ve proje olması gerektiği gibi düzenlenmiştir. Visual Studio'da bir seçeneği etkinleştirerek tüm bağımlılıkları her zaman otomatik olarak indirir.

Tabii ki sadece git (başka bir repo, alt modüller vb.) Kullanan bir çözüm kullanabilirsiniz, ancak bu sadece hack'tir. Doğru şekilde yapmak hızlı bir şekilde ödeme yapacak ve sizi geleceğe hazır bir sisteme bırakacaktır.

Yorumlardan sonra düzenleme: NuGet'i kullanmanın en iyi yolu, paylaşılan bir sürücüde veya tam bir nuget sunucusunda yerel bir NuGet kaynağı kurmaktır. Kurulum her iki şekilde de birkaç dakikadan fazla sürmemelidir. Bu şekilde, nereden olursa olsun, ihtiyacınız olan tüm paketlerin her zaman kullanılabilir olmasını garanti edebilirsiniz.

Aletler için alt modülleri kullanabilirsiniz . Bu şekilde onları şimdi yaptığınız gibi bir alt dizinde tutabilir ve sürümlendirmek için ayrı bir repo kullanabilirsiniz. Bu aynı zamanda araçları klonlayabileceğiniz (kontrol edebileceğiniz) ve ayrı ayrı geliştirebileceğiniz ve diğer projelerin bu depolara ve bunların belirli, uyandırılabilir sürümlerine de güvenebileceği anlamına gelir.

Üçüncü parti kütüphaneler için alt modülleri de kullanabilirsiniz, ancak mümkünse bunlar için bir bağımlılık yöneticisi kullanmanızı tavsiye ederim.

Git depolarına çevirdiğiniz varlıklar mutlaka sürüm ve şube yaptığınız varlıklardır; eğer SolutionFolder/Tools/Tool1böyle bir şeye karşılık gelirse , bu varlık seviyesidir. Git bir olması (hatta iyi bir fikir değil ise) svn ile mümkündür, oysa versionable varlık olarak dizin ağacının her haline ilişkin Bunun nedeni trunk, branchesve tagsher yerde ağacın içinde.

Türetilmiş eserler depoda veya harici kütüphanelerde tutulmamalıdır. Bunlarla başa çıkmanın daha iyi yolları var. (Java ile çalışıyorsanız, özel bir Maven deposu kullanmayı düşünün; Onlarla çalışmak nispeten kolaydır ve diğer birçok şeyle güzel bir şekilde bütünleşir.)

Ödeme kolaylığı için tek bir depoda her şeye sahip bir iş akışına alışkınsanız, bunun yerine işleri ayarlayan bir komut dosyasına sahip olmayı düşünün.

Dürüst olmak gerekirse, kurulumunuzda hiçbir şeyi değiştirmezdim. Şimdi tam olarak bunu yapıyoruz. Kullandığımız üçüncü taraf lib'i işlemek için ayrı bir git deposu kurarak oynuyordum, ancak taşınabilirlik maliyetine kadar ağır olduğunu düşünmüyorum. Artık herhangi bir geliştirici, herhangi bir manuel kurulum işlemi yapmak zorunda kalmadan ödeme yapabilir ve başlayabilir. Ve ben herhangi bir yapı sunucusu / köle proje inşa edebilirsiniz. Üç parçalı araçları paylaşan çoklu depolarınız olmadıkça, şu anki kurulumunuza sadık kalırım.

Birlikte oynadığım üçüncü taraf araçlarını ayrı bir repoda kurmaktı. Sonra sha1 ref ile bir metin dosyasını okumak ve doğru sürümü ödeme basit bir toplu komut dosyası vardı. Bu, farklı projeler için farklı üçüncü taraf sürümlerine sahip olmamı sağlayacaktır. Bu fikri Facebook Buck derleme aracından aldım. Ama sonunda birçok geliştirici komut satırı araçlarını (MS VC mağazası) kullanmaktan hoşlanmıyor, bu yüzden bu fikirden vazgeçtim.

Üçüncü taraf kütüphanelerinizi ihtiyaç duyduğunuzda (NuGet kullanarak) indirmemenizin önemli bir nedeni, ürününüzü uzun süre desteklemeniz gerektiğidir. Sektörümde, bazen eski üçüncü taraf kütüphanelerine dayanan eski sürümler için güncellemeler sağlamalıyız. Hangi lbs'leri yükseltebileceğimizi veya edemeyeceğimizi sıralamak için çok fazla zaman harcamak istemiyoruz ve sadece bu versiyonda kullanılan libs'i kullanıyoruz. Şimdi NuGet'i kullandığınızı düşünün, ayy ... ihtiyacınız olan lib'in en son sürümü 3.98 ama 2.04'e ihtiyacınız var ..... patronunuza eski sürümü yükseltmek için 2 ay harcamanız gerektiğini nasıl açıklayacağınızı küçük bir değişiklik beklerken en son libs kullanmak için!