Tôi vẫn là một người dùng Subversion khác đang đấu tranh để giáo dục lại bản thân mình trong Tao về kiểm soát phiên bản phân tán.
Khi sử dụng Subversion, tôi là một fan hâm mộ lớn của dự án - phương pháp tiếp cận nhỏ và, với hầu hết các chủ nhân trước đây của tôi, chúng tôi sẽ cấu trúc các chi nhánh kho lưu trữ của chúng tôi; thẻ & thân cây như sau:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
Trong chính cây nguồn thực tế, chúng ta sẽ sử dụng (một cái gì đó giống như) cấu trúc sau:
(src)-+
+-developmentAutomation-+
| +-testAutomation
| +-deploymentAutomation
| +-docGeneration
| +-staticAnalysis
| +-systemTest
| +-performanceMeasurement
| +-configurationManagement
| +-utilities
+-libraries-+
| +-log-+
| | +-build
| | +-doc
| | +-test
| +-statistics-+
| | +-build
| | +-doc
| | +-test
| +-charting-+
| | +-build
| | +-doc
| | +-test
| +-distributedComputing-+
| | +-build
| | +-doc
| | +-test
| +-widgets-+
| +-build
| +-doc
| +-test
+-productLines-+
| +-flagshipProduct-+
| | +-coolFeature
| | +-anotherCoolFeature
| | +-build
| | +-doc
| | +-test
| +-coolNewProduct
+-project-+
+-bigImportantCustomer-+
| +-bespokeProjectOne
| +-bespokeProjectTwo
+-anotherImportantCustomer-+
+-anotherBespokeProject
Ý tưởng là (và vẫn là) sử dụng cấu trúc của kho lưu trữ để giúp cấu trúc giao tiếp giữa nhóm kỹ sư; bộ phận khách hàng của doanh nghiệp và các bên liên quan khác & các chuyên gia tên miền.
Để dí dỏm: Các tài liệu nguồn nằm trong một trong các thư mục "dự án" chỉ được sử dụng (và kiếm tiền) một lần. Các tài liệu nằm trong một trong các thư mục "sản phẩm" kiếm được tiền nhiều lần khi một sản phẩm từ dòng cụ thể đó được bán. Các tài liệu nằm trong một trong các thư mục "thư viện" kiếm được tiền gấp nhiều lần bất kỳ sản phẩm nào sử dụng chúng được bán.
Nó làm cho khái niệm khấu hao chi phí rõ ràng và giúp xây dựng hỗ trợ cho việc tái sử dụng tài liệu nguồn trên toàn doanh nghiệp.
Điều đó cũng có nghĩa là có một cấu trúc chung mà các công cụ tự động hóa xây dựng của chúng tôi có thể vận hành. (Các tập lệnh xây dựng của chúng tôi đi trên cây nguồn tìm kiếm các thư mục "xây dựng" trong đó chúng tìm thấy các tệp cấu hình chỉ định cách xây dựng từng thành phần; một quá trình tương tự xảy ra để tạo và kiểm tra tài liệu).
Đáng kể, các sản phẩm mà tôi làm việc thường mất nhiều thời gian để chạy các bài kiểm tra đo lường và đặc tính hiệu suất; từ 20 đến 200 giờ; tạo ra một nơi nào đó giữa vài GB đến vài TB kết quả kiểm tra / dữ liệu trung gian đã xử lý (phải được lưu trữ và gắn với một cấu hình hệ thống cụ thể để có thể đo lường cải thiện hiệu suất theo thời gian). Vấn đề này làm cho việc quản lý cấu hình trở thành một sự cân nhắc quan trọng và cũng đặt ra một số yêu cầu cho việc tập trung hóa, vì thông thường các tài nguyên tính toán cần thiết để chạy các phép đo đặc tính và kiểm tra hiệu năng bị hạn chế; (một cụm nhỏ gồm 64-128 lõi).
Như một lưu ý cuối cùng; hệ thống tích hợp liên tục biết rằng nó cần kích hoạt một bản dựng; phân tích tĩnh; kiểm tra khói & kiểm tra đơn vị chạy mỗi lần thân cây được sửa đổi, mỗi lần bất kỳ nhánh "thẻ" nào được sửa đổi và mỗi lần bất kỳ nhánh nhánh "TỰ ĐỘNG" nào được sửa đổi. Bằng cách này, các nhà phát triển cá nhân có thể sử dụng hệ thống CI với các chi nhánh cá nhân của họ, một khả năng quan trọng, IMHO.
Bây giờ, đây là câu hỏi của tôi: Làm thế nào tôi có thể sao chép tất cả những điều trên (và cải thiện nó, nếu có thể), với Mercurial.
--biên tập:
Dòng suy nghĩ hiện tại của tôi là sử dụng Kho lưu trữ Subversion trung tâm, để xác định cấu trúc tổng thể, nhưng cho phép sử dụng hg như một máy khách để các nhà phát triển có thể có kho lưu trữ có sẵn tại địa phương.