Khi nào một dự án đa mô-đun sẽ được chia thành các cây kho riêng biệt?

Question

Hiện nay chúng tôi có một dự án với một bố trí kho subversion tiêu chuẩn:

./trunk
./branches
./tags

Tuy nhiên, như chúng ta đang di chuyển xuống đường của OSGi và một dự án mô đun, chúng tôi đã kết thúc với:

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0. 0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

Các 'xây dựng' vẫn còn khá nguyên khối ở chỗ nó được xây dựng tất cả các module theo thứ tự, mặc dù tôi đang bắt đầu tự hỏi nếu chúng ta nên cấu trúc lại build/kho để một cái gì đó giống như:

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main /tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

Trong mẫu này, tôi sẽ tưởng tượng mỗi bản thân xây dựng mô đun và lưu trữ nhị phân của nó trong một kho lưu trữ (maven, ivy hoặc một đường dẫn khác của kho lưu trữ subversion).

Có nguyên tắc hoặc 'thực hành tốt nhất' trên bố cục dự án khi một mô đun đi theo mô-đun không?

Answer 1

Cuốn sách Subversion chứa hai phần về điều này:

• Repository Layout
• Planning Your Repository Organization

Một blog entry về đề tài này: "Subversion Repository Layout"

Câu trả lời ngắn, mặc dù: khi bạn số dặm sẽ khác nhau (mỗi trường hợp là cá nhân), sơ đồ /bundle/<project>/(trunk|tags|branches) của bạn khá phổ biến và sẽ có khả năng làm việc tốt cho bạn.

Answer 2

này là rất nhiều đến sở thích cá nhân, nhưng tôi tìm ra cấu trúc sau đây phù hợp cho các dự án lớn bao gồm nhiều module:

 
branches 
    project-name 
    module1 
     branch-name 
    module2 
     possibly-another-branch-name 
    branch-name-on-a-higher-level-including-both-modules 
     module1 
     module2 
tags 
    ... (same as branches) 
trunk 
    project-name 
    module1 
    module2 

Tôi cũng thường được sử dụng cấu trúc trong các kho lớn chứa nhiều dự án, bởi vì việc giữ tất cả các dự án trong cùng một kho lưu trữ làm cho các dự án tham chiếu chéo và chia sẻ mã giữa chúng — với lịch sử — dễ dàng hơn.

Tôi thích sử dụng cấu trúc với thư mục gốc, thẻ và thư mục từ đầu vì trong kinh nghiệm của tôi (với kho lưu trữ lớn chứa nhiều dự án), nhiều tiểu dự án và mô-đun sẽ không bao giờ có thẻ hoặc chi nhánh riêng biệt không cần tạo cấu trúc thư mục cho chúng. Nó cũng làm cho nó dễ dàng hơn cho các nhà phát triển để kiểm tra toàn bộ thân cây của kho lưu trữ và không nhận được tất cả các thẻ và các chi nhánh (mà họ không cần hầu hết thời gian).

Tôi đoán đây là vấn đề về chính sách của dự án hoặc công ty. Nếu bạn có một kho lưu trữ cho mỗi dự án hoặc một nhà phát triển nhất định chỉ có khả năng làm việc trên một dự án duy nhất trong kho lưu trữ tại một thời điểm thân cây gốc có thể không có ý nghĩa nhiều.

Answer 3

Tôi đã trả lời một câu hỏi tương tự trong StackOverflow Version Control Structure question. Nó thực sự phù hợp hơn nữa ở đây kể từ khi chúng tôi phát triển OSGi nặng và có rất nhiều gói. Tôi phải echo Anders Sandvig ý kiến: giữ thân cây/thẻ/chi nhánh ở cấp cơ sở vì bạn sẽ chỉ chi nhánh một tập hợp các mô-đun hạn chế. Nó cũng không can thiệp vào các mô-đun xây dựng riêng lẻ.

Tôi sẽ không sao chép câu trả lời tôi đã đưa ra trước đây nhưng nó hoàn toàn liên quan đến câu hỏi này.

Answer 4

Chỉ cần hai xu của tôi ...

Tôi chỉ muốn nhấn mạnh những nhận xét trong tài liệu SVN (đã được trích dẫn trong câu trả lời khác, cùng một chủ đề) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

Đoạn trích tham chiếu cấu trúc sau: / trunk/ calc/ lịch/ bảng/ ... thẻ/ calc/ lịch/ bảng/ ... chi nhánh/ calc/ lịch/ bảng/

"Không có gì đặc biệt không chính xác về bố cục như vậy là, nhưng nó có thể hoặc không có thể có vẻ như trực quan cho người dùng của bạn. Đặc biệt trong các tình huống lớn, đa dự án với nhiều người dùng, những người dùng đó có thể có xu hướng quen thuộc với chỉ một hoặc hai dự án trong kho lưu trữ. Nhưng các anh chị em của dự án cũng như chi nhánh có khuynh hướng nhấn mạnh tính cá nhân của dự án và tập trung vào toàn bộ các dự án như một thực thể duy nhất. Đó là một vấn đề xã hội. Chúng tôi thích sự sắp xếp được đề xuất ban đầu của chúng tôi vì lý do thực tế — dễ dàng hơn để hỏi về (hoặc sửa đổi hoặc di chuyển ở nơi khác) toàn bộ lịch sử của một dự án duy nhất khi có một đường dẫn lưu trữ duy nhất chứa toàn bộ lịch sử - quá khứ, hiện tại, được gắn thẻ và . nhánh cho rằng dự án và dự án mà một mình"

đối với riêng tôi, tôi có xu hướng đồng ý khá mạnh mẽ với điều này và thích cách bố trí như sau: / utils/ calc/ trunk/ thẻ/ chi nhánh/ lịch/ trunk/ thẻ/ chi nhánh/ ….210 văn phòng/ bảng/ trunk/ Thẻ/ chi nhánh/

Lý do chỉ đơn giản là rằng nó không thực tế để gắn thẻ một bộ dự án hoàn thành khi người ta sẽ muốn gắn thẻ chỉ là một tập hợp con cụ thể.

Hãy sử dụng ví dụ: Nếu project-1 phụ thuộc vào moduleA v1.1 và moduleB v2.3, tôi không muốn mô-đun v2A mới hơn xuất hiện trong thẻ. Trong thực tế, khi quay lại vài ngày/tuần/tháng sau khi phát hành được gắn thẻ này, tôi sẽ buộc phải mở bộ mô tả gói trong phiên bản được gắn thẻ của dự án-1 để đọc phiên bản của moduleA thực sự cần thiết.

Hơn nữa, nếu tôi phải sao lưu cụ thể các nguồn của bản phát hành này vào đĩa CD, tôi chỉ muốn xuất thẻ này mà không tải xuống hàng trăm megabyte nội dung không liên quan.

Đó chỉ là hai xu của tôi.