Monolithic vs nhiều Repos Mercurial cho các mô-đun trong một bộ ứng dụng liên quan

Question

Tại tổ chức của tôi, chúng tôi muốn chuyển từ sử dụng CVS sang Mercurial vì nhiều lý do. Chúng tôi đã thực hiện rất nhiều điều tra khi cố gắng xác định cách chúng tôi nên tổ chức kho lưu trữ Hg của mình dựa trên những gì chúng tôi có trong codebase của chúng tôi và cách chúng tôi có xu hướng hoạt động. Chúng tôi đã đưa ra các câu trả lời thỏa đáng cho hầu hết các câu hỏi của chúng tôi, nhưng có một điểm khiến chúng tôi lo lắng một chút và điều đó khiến tôi phát điên vì cách thuận tiện nhất để tổ chức repo cho quy trình làm việc của chúng tôi dường như là một cách sai lầm một quan điểm khái niệm. Tôi đang cố gắng tìm hiểu xem liệu nhận thức của chúng tôi về cách thức này "được cho là" để làm việc là sai, hoặc cho dù chúng ta chỉ chạm vào một khoảng cách tính năng hợp pháp trong công cụ có sẵn.

Chủ yếu là chúng tôi duy trì một codebase cỡ trung bình bao gồm một bộ ứng dụng nhận được tất cả được phát hành trong cùng một gói. Về mặt lý thuyết bạn có thể chia mã của chúng tôi thành ba loại:

1. đang chia sẻ
đang
2. Đơn xin bộ chính của chúng tôi (sử dụng mã chia sẻ)
3. tiện ích nhỏ khác được thường xuyên duy trì (sử dụng mã chia sẻ)

Điều này dường như không bình thường đối với tôi, nhưng tôi muốn nhấn mạnh điểm chúng tôi duy trì mã ứng dụng và mã được chia sẻ cùng một lúc và luôn muốn chúng xuất hiện cạnh nhau. Tức là, chúng tôi muốn tất cả các ứng dụng của chúng tôi xây dựng để luôn sử dụng phiên bản mới nhất và cùng một phiên bản của mã được chia sẻ. Chúng tôi thường xuyên thêm hoặc sửa đổi mã ứng dụng và mã được chia sẻ cùng một lúc. Hiện tại, mã chia sẻ nằm trong một mô-đun CVS và các ứng dụng đều nằm trong các mô-đun riêng biệt của chúng. Mã chia sẻ và các mô-đun ứng dụng được kiểm tra sao cho mã chia sẻ được xây dựng một lần và sau đó được liên kết vào từng ứng dụng. Chúng tôi thường xuyên thực hiện các cam kết cvs bao gồm các thay đổi trên các mô-đun chia sẻ và ứng dụng cùng một lúc. Chúng tôi thực sự muốn giữ khả năng đó.

Tôi hiểu rằng cam kết trong Hg là nguyên tử trong kho - đó là tốt nhưng tôi muốn có thể khác và cam kết với một ứng dụng và thư viện được chia sẻ tại cùng một thời điểm (nghĩa là tôi không quan tâm nếu nó thực sự nguyên tử nhưng tôi không muốn phải tự làm hai khác biệt riêng biệt và hai hành động cam kết riêng biệt).

Về mặt khái niệm, có vẻ như sẽ đúng khi có một hoặc một vài bản repo cho mã được chia sẻ và một repo riêng cho từng ứng dụng và mỗi chương trình tiện ích nhỏ. Điều này có nghĩa là bạn cần phải kiểm tra nhiều bản ghi nhớ cho mỗi bản dựng nhưng đó không phải là vấn đề đối với chúng tôi. Vấn đề là dường như không có bất kỳ công cụ nào cho phép bạn xem các cập nhật hoặc thay đổi trên nhiều repos cùng một lúc, hoặc nhiều repos khác nhau cùng một lúc và sau đó liên tục cam kết chúng cho bạn. Điều này sẽ dễ dàng để kịch bản, nhưng điều đó sẽ không giúp các nhà phát triển, những người muốn sử dụng giao diện đồ họa khác nhau để bổ sung cho dòng lệnh.

Nó có vẻ như để có thể cam kết trên nhiều codebases cùng một lúc (từ quan điểm của người dùng) và giữ cho mọi thứ trên bờ chảy máu với nhau, chỉ có hai giải pháp là:

1. Sử dụng một repo nguyên khối với mọi thứ trong đó.
2. Tạo một số subrepos nhưng truy cập/cam kết tất cả mọi thứ thông qua một repo "chính" nguyên khối chứa tất cả các subrepos để giữ mọi thứ trên bản sửa đổi mới nhất (có vẻ như không tốt hơn (1) với tôi).

Không thể là điều bất thường khi muốn làm việc với nhiều kho "ngang hàng" cùng một lúc, ngay cả khi các hành động không thực sự nguyên tử trên tất cả chúng - và tôi không tìm thấy tấn bài viết hoặc bài đăng kêu gọi khả năng này.

Nói tóm lại:

1. Chúng tôi muốn tổ chức mã của chúng tôi như vậy mà chúng ta có thể diff và cam kết mã ứng dụng và mã chia sẻ cùng lúc từ quan điểm của người dùng (họ không cần phải thực sự được nguyên tử).
2. Có vẻ như chúng ta nên đặt mã ứng dụng và mã được chia sẻ trong các kho lưu trữ riêng biệt.
3. Cụm phụ đề liên kết kho lưu trữ gốc với các bản sửa đổi cụ thể mà chúng tôi không muốn.

Tôi thiếu gì ở đây?

Answer 1

Trong cửa hàng của tôi, chúng tôi có nhiều dự án chỉ đơn giản là trong repo riêng biệt, nhưng repo của ứng dụng chính có 2 dự án khác trong đó. Một là một mô-đun chia sẻ một số lượng đáng kể mã với ứng dụng chính, và cái kia là để di chuyển cơ sở dữ liệu cho ứng dụng (nó thậm chí còn bằng một ngôn ngữ khác). Tôi muốn những thay đổi có liên quan trong cả ứng dụng và người di chuyển được cam kết với nhau, không thể tách rời. Nhìn chung, tất cả các tệp nguồn trong repo này nằm trong khoảng từ 10 đến 11 MB. Vì vậy, nếu đặt tất cả mọi thứ trong một kho lưu trữ thực sự là những gì có ý nghĩa bởi vì bạn không muốn đối phó với subrepositories, sau đó không có gì sai với việc đặt tất cả mọi thứ trong một kho lưu trữ. Một trong những của tôi là về phía nhỏ của phương tiện, theo ý kiến ​​của tôi. Nguồn của TortoiseHg là khoảng 20 MB, OGRE là hơn 100 MB.

Nếu không biết nhiều hơn về dự án của bạn và mối quan hệ của họ, ấn tượng tôi nhận được là một kho lưu trữ sẽ hoạt động tốt và bạn không xem xét điều này một cách không chính xác.

Nếu bạn thay đổi ý định, hg convert có thể giúp bạn trích xuất dự án vào kho lưu trữ của riêng họ, duy trì lịch sử của các tệp đó.

Nếu cách tiếp cận một kho không dành cho bạn, thì tôi nghĩ rằng subrepos sẽ có cơ hội, vì đó là phương pháp duy nhất tôi biết để xử lý nhiều repos liên kết được hỗ trợ trong TortoiseHg (xem phần Recommendations).

Tuy nhiên, tôi không chắc chắn cách bạn xử lý truy cập liên phòng, với điều kiện dường như không có tập con được thiết lập đã được chia sẻ với người khác.