Chuyển một repo SVN nhiều GB sang Git

Hiện tại công ty của tôi có một đơn vị Visual Studio trong một repo SVN được tổ chức như sau:

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

Tool1 và Tool2 được xây dựng độc lập (có giải pháp riêng), nhưng tạo ra các tệp thực thi được sử dụng trong bản dựng chính. Thư mục ThirdParty chứa tất cả các phụ thuộc cho dự án, bao gồm một số tệp .lib 100+ MB được biên dịch sẵn và các thư viện lớn như boost.

Thật tiện lợi khi có tất cả trong một repo SVN để (1) nhà phát triển chỉ phải thực hiện một lần thanh toán và (2) chúng tôi không cần theo dõi phiên bản phụ thuộc nào chúng tôi cần cho mỗi phiên bản của bản dựng. Mặt khác, phải mất một thời gian để kiểm tra repo này.

Điều gì sẽ là cách tốt nhất để di chuyển cấu trúc dự án này sang git? Có lẽ tốt nhất là loại trừ ThirdParty và có thể là Công cụ khỏi repo chính, nhưng chúng tôi muốn giữ cho ThreeParty có thể tải xuống dễ dàng trong một bước và chúng tôi thích phiên bản đó (và phiên bản không khớp giữa repo chính và ThirdParty / Tools sẽ không tốt).

Tại thời điểm này tôi không quan tâm đến việc bảo tồn lịch sử, chỉ cần tìm ra cách tổ chức dự án đó.

Sử dụng các công cụ thích hợp cho công việc. Trong Windows, điều đó có nghĩa là

Sử dụng NuGet cho các phụ thuộc của bên thứ ba

Bằng cách đó, bạn giữ các phụ thuộc của bên thứ ba theo cách được phiên bản, nhưng bạn sẽ không làm hỏng kho lưu trữ của mình với những thứ không cần thiết. Kiểm tra nhanh hơn nhiều, và dự án được tổ chức như nó phải được. Bạn có thể kích hoạt một tùy chọn trong Visual Studio để nó luôn tự động tải xuống tất cả các phụ thuộc.

Tất nhiên bạn có thể sử dụng một giải pháp chỉ sử dụng git (một repo khác, mô đun con, v.v.), nhưng đó chỉ là hack. Làm theo cách đúng đắn sẽ nhanh chóng được đền đáp và để lại cho bạn một hệ thống chứng minh trong tương lai.

Chỉnh sửa sau khi nhận xét: Cách tốt nhất để sử dụng NuGet là thiết lập nguồn NuGet cục bộ, trên ổ đĩa chung hoặc máy chủ nuget đầy đủ. Thiết lập không nên mất nhiều hơn một vài phút. Bằng cách đó, bạn có thể đảm bảo rằng tất cả các gói bạn cần luôn có sẵn, bất kể chúng có nguồn gốc từ đâu.

Bạn có thể sử dụng mô hình con cho các công cụ. Bằng cách đó, bạn có thể giữ chúng trong thư mục con như bạn hiện tại và sử dụng một repo riêng để tạo phiên bản cho chúng. Điều đó cũng có nghĩa là bạn có thể sao chép (kiểm tra) các công cụ và phát triển chúng một cách riêng biệt, và các dự án khác có thể dựa vào các repos đó - và trên các phiên bản cụ thể, có thể chấp nhận được của chúng.

Bạn cũng có thể sử dụng các mô hình con cho các thư viện bên thứ ba, nhưng nếu có thể, tôi sẽ khuyên bạn nên sử dụng trình quản lý phụ thuộc cho các thư viện đó.

Các thực thể mà bạn chuyển thành kho git nhất thiết phải là các thực thể mà bạn phiên bản và chi nhánh; nếu SolutionFolder/Tools/Tool1tương ứng với một điều như vậy, đó là mức độ thực thể. Điều này là do git coi toàn bộ trạng thái của cây thư mục là thực thể có thể thay đổi được, trong khi với svn thì có thể (ngay cả khi không phải là một ý tưởng tốt) để có một trunk,branches vàtags bất cứ nơi nào trong cây.

Các đồ tạo tác có nguồn gốc không nên được giữ trong kho lưu trữ, cũng như các thư viện bên ngoài. Có nhiều cách tốt hơn để xử lý chúng. (Nếu bạn đang làm việc với Java, hãy cân nhắc sử dụng kho lưu trữ Maven riêng; chúng tương đối dễ làm việc và tích hợp độc đáo với nhiều thứ khác.)

Nếu bạn đã quen với một quy trình làm việc có mọi thứ trong một repo để dễ kiểm tra, hãy xem xét việc có một kịch bản thiết lập mọi thứ thay thế.

Thành thật mà nói tôi sẽ không thay đổi bất cứ điều gì trong thiết lập của bạn. Nó chính xác là những gì chúng ta đang làm bây giờ. Tôi đã chơi xung quanh với việc thiết lập một kho lưu trữ git riêng để xử lý lib của bên thứ ba mà chúng tôi sử dụng nhưng tôi không nghĩ rằng nó nặng đến chi phí tính di động. Bây giờ bất kỳ nhà phát triển nào cũng có thể kiểm tra và bắt đầu mà không cần phải thực hiện bất kỳ bước thiết lập thủ công nào. Và tôi bất kỳ máy chủ xây dựng / nô lệ có thể xây dựng dự án. Trừ khi bạn có nhiều repos chia sẻ các công cụ thridparty, tôi sẽ chỉ gắn bó với thiết lập hiện tại của bạn.

Những gì tôi đã chơi xung quanh là thiết lập các công cụ của bên thứ ba trong một repo riêng. Sau đó, tôi đã có một tập lệnh bó đơn giản đọc một tệp văn bản với tham chiếu sha1 và kiểm tra phiên bản chính xác. Điều này sẽ cho phép tôi có các phiên bản bên thứ ba khác nhau cho các dự án khác nhau. Tôi có ý tưởng này từ công cụ xây dựng Facebook Buck. Nhưng cuối cùng, nhiều nhà phát triển không thích sử dụng các công cụ dòng lệnh (cửa hàng MS VC tại đây) nên tôi đã từ bỏ ý tưởng này.

Một lý do chính tại sao không tải xuống libs của bên thứ ba khi bạn yêu cầu chúng (sử dụng NuGet) là nếu bạn cần hỗ trợ sản phẩm của mình trong một thời gian dài. Trong ngành của tôi, đôi khi chúng tôi cần cung cấp các bản cập nhật cho các phiên bản cũ dựa trên libs của bên thứ ba cũ. Chúng tôi không muốn mất nhiều thời gian để phân loại những lib nào chúng tôi có thể nâng cấp hay không và chỉ sử dụng các lib như được sử dụng trong phiên bản đó. Bây giờ hãy tưởng tượng bạn sử dụng NuGet, ôi ... phiên bản mới nhất của lib bạn yêu cầu là 3,98 nhưng bạn cần 2.04 ..... làm thế nào để giải thích với sếp rằng bạn cần mất 2 tháng để nâng cấp phiên bản cũ để có thể để sử dụng libs mới nhất khi anh ấy đang mong đợi một thay đổi nhỏ!