Quản lý các nguồn và mã nhị phân của bên thứ ba được sử dụng bởi mã dưới sự kiểm soát nguồn

Question

Tôi có một cơ sở mã lớn dưới sự kiểm soát nguồn (đã bị lật đổ, bây giờ git). Để biên dịch mã và chạy thử nghiệm, tôi sử dụng một tập hợp các thư viện của bên thứ ba. Những thư viện có thể được chia thành vài categoriesL

• Binaries chỉ
• nguồn bên thứ 3
• nguồn bên thứ 3 + thay đổi địa phương

Mỗi thư viện có của nó {Windows, Linux} X {debug, release} Cấu hình X {32bit, 64bit}. Ngoài ra, các thư viện này phát triển theo thời gian và các phiên bản khác nhau của dự án của tôi sử dụng các phiên bản/xây dựng khác nhau của các thư viện này.

Câu hỏi của tôi là cách tốt nhất để lưu trữ các bên thứ ba này là gì?

Dưới đây là bộ của tôi về sở thích:

1. Giữ kích thước của kho lưu trữ nguồn dự án nhỏ
2. Giữ nguồn dự án đồng bộ với các bên thứ 3 vì vậy tôi luôn có thể biên dịch và chạy và phiên bản cũ
3. đơn giản để quản lý
4. chéo nền tảng

tôi đã cố gắng và suy nghĩ của một số giải pháp nhưng không thỏa đáng:

1. Sử dụng tập lệnh được phiên bản để tìm nạp tệp nhị phân từ máy chủ ftp được quản lý thủ công chứa tất cả phiên bản của thư viện. Điều này hoạt động, nhưng yêu cầu quản lý cẩn thận cấu trúc thư mục trên máy chủ. Đó là lỗi dễ bị như ai đó có thể ghi đè lên một trong những tập tin nhị phân với một xây dựng mới.
2. SVN externals - Tại thời điểm SVN externals không thể tham chiếu đến một thẻ cụ thể. Hôm nay tôi đang sử dụng git.
3. Mô-đun con Git - Kéo toàn bộ kho lưu trữ bên ngoài có thể rất lớn. Ngoài ra, nó yêu cầu quản lý một kho lưu trữ riêng biệt cho mỗi thư viện. Các submodule điểm tại một thẻ cụ thể có nghĩa là hoặc là tôi nhận được tất cả các bên ngoài, khi tôi chỉ cần một số, hoặc tôi bắt chước một số hệ thống tập tin lạ trong cây git.

Rõ ràng với tôi rằng các nguồn của bên thứ ba cần phải được lưu trữ trong git trong chi nhánh nhà cung cấp, nhưng các tệp nhị phân và tiêu đề là một câu chuyện khác.

Answer 1

Giải pháp hợp lý cho vấn đề của tôi là git-subtree gần đây đã được hợp nhất thành git chính. Nó cung cấp một sự cân bằng hợp lý giữa các yêu cầu của tôi và các hạn chế nền tảng. Bây giờ tôi có nhiều kho lưu trữ cho các phần tử bên ngoài (mỗi nhánh có một nhánh của nhà cung cấp cũng như các nhánh thay đổi cục bộ) và mỗi kho dự án lấy các phần của các phần tử bên ngoài này vào các thư mục con. Để giữ mọi thứ có tổ chức, tôi duy trì một thư mục 'bin' và 'lib' chứa các liên kết mềm tới các tệp/thư mục thích hợp trong thư mục con bên ngoài.

git-subtree cho phép hợp nhất cây con từ một kho lưu trữ bên ngoài vào thư mục con. Thư mục con có thể được hợp nhất qua lại với kho lưu trữ bên ngoài.

Ưu/Nhược điểm:

1. nhỏ kho - Kho dữ liệu không phải là nhỏ như tôi muốn nó được nhưng nó chỉ chứa những phần cần thiết từ các kho bên ngoài. Để tiết kiệm không gian, tôi cố gắng giữ cho các cây bên ngoài nhỏ. Tôi coi nó là một mức giá tốt để trả khi tôi đổi lại, tôi nhận được sự đơn giản và mạnh mẽ; khi tải và cập nhật dự án là kéo git đơn giản và tất cả dữ liệu liên quan đến dự án được chứa trong một kho lưu trữ đơn lẻ

2. Project/Externals - Do dự án và bên ngoài được phiên bản trong cùng một kho lưu trữ, tôi có thể thanh toán mọi chi nhánh/tôi muốn và mong đợi nó hoạt động.

3. Tính đơn giản - Công việc hàng ngày là thẳng về phía trước. Cập nhật kho lưu trữ bên ngoài, tạo một kho lưu trữ mới hoặc chuyển sang phiên bản khác của bên ngoài có thể phức tạp và đòi hỏi cú pháp đặc biệt. Tuy nhiên điều này không xảy ra quá nhiều. Điều tốt nhất là người ta có thể thêm một bên ngoài mới vào dự án này trước tiên và chỉ sau đó chia nó ra (sử dụng git-subtree) vào kho lưu trữ của chính nó.

4. nền tảng Cross - Vâng đó là git

5. Binaries - Tôi quyết định để tránh giữ mã nhị phân và cung cấp Makefiles để thay thế. Tôi đã đi đến quyết định này vì một số bên ngoài của tôi phụ thuộc vào các phần tử bên ngoài khác, làm cho việc xây dựng một tệp nhị phân không thay đổi thường xuyên rất khó. Đối với một số bên ngoài, tôi lưu trữ các tệp nhị phân do thời gian xây dựng rất dài.

Cấu trúc:

/root 
    /External 
     /External1 (git-subtree from git@git.domain.com:External1 v1.0) 
     /External2 (git-subtree from git@git.domain.com:External2 v0.7) 
    /lib 
     /libExternal1.a -> ../External/External1/libExternal1.a 
     /libExternal2.a -> ../External/External1/libExternal2.a 
    /include 
     /External1 -> ../External/External1/include 
     /External2 -> ../External/External2/include 

Answer 2

Chúng tôi đã đi cho một biến thể của tùy chọn của bạn 3. Tùy chọn 1 dường như tôi tương đương với Tùy chọn 3, nhưng với nhiều nỗ lực thực hiện/kiểm tra hơn một phần của bạn và do đó nhiều khả năng đi sai.

Cuối cùng, nếu bạn muốn có thể tạo lại chính xác một bản dựng, bạn sẽ cần các phần bên ngoài của bạn (bao gồm cả tệp nhị phân) được phiên bản cùng với mã và được lưu trữ cục bộ. Và git submodules sẽ làm tốt công việc này cho bạn.

Answer 3

Đối với nguồn của bên thứ ba, tôi nghĩ rằng mô-đun con là chính xác những gì bạn đang tìm kiếm. Nếu bạn không muốn yêu cầu toàn bộ lịch sử ngược dòng trong mọi bản sao, hãy đặt giao diện repo ngược dòng của riêng bạn, chứa nhánh thủ công chỉ với lịch sử cần thiết. Hãy xem số git commit-tree để xem cách tạo những thứ đó, thật dễ dàng.Id cam kết sẽ không khớp với thượng nguồn có thẩm quyền, nhưng ý chí của id cây.

Đối với các tệp nhị phân, git annex có vẻ là cách được khuyến nghị nhiều nhất để lưu trữ nội dung không phù hợp với trọng tâm phân tán nguồn của git. Tôi đã không sử dụng nó bản thân mình nhưng thiết kế có vẻ sẵn sàng để sử dụng sản xuất, nó cũng hỗ trợ nhiều kho độc lập `và trông về thuận tiện như nó có thể hợp lý được.

Đây không phải là chìa khóa trao tay, vì vậy nó không thực sự đáp ứng được phần ba của bạn, nhưng nó sẽ giúp phần còn lại và những gì bạn cần là sử dụng đơn giản các công cụ cơ bản.