Perforce Dev Branches - Chi nhánh thưa thớt so với chi nhánh tư nhân

Question

Tôi đang tìm một số phản hồi về những ưu điểm và nhược điểm của các phương pháp sẵn có để tạo các nhánh phát triển riêng lẻ trong kho lưu trữ Perforce. Nếu tôi hiểu chính xác, có hai cách để xử lý việc này. Đầu tiên là tạo một nhánh riêng, là một bản sao hoàn chỉnh của nhánh mà bạn đang làm việc. Chi nhánh sẽ hoàn toàn đứng riêng và hoàn toàn cô lập các thay đổi của bạn từ nhánh mục tiêu.

Phương pháp khác mà tôi đã nghe được đề xuất là Phân nhánh thưa thớt. Nó được mô tả trong Practical Perforce (Chương 9, tr.242). Điều này tạo ra một chi nhánh, nhưng chỉ với các tập tin mà bạn sẽ cần phải chỉnh sửa. Sau đó, bạn chồng chéo khung nhìn khách hàng nhánh mục tiêu với khung nhìn khách hàng chi nhánh dev thưa thớt này.

Cả hai phương pháp đều sẽ yêu cầu người lập trình thực hiện một số công việc tích hợp để có được những thay đổi của họ trong nhánh mục tiêu. Phương thức Private Branch có vẻ như nó sẽ đòi hỏi nhiều bộ nhớ bổ sung hơn để tạo ra một bản sao của toàn bộ nhánh. Tuy nhiên, các tài liệu Perforce nói rằng nó thực hiện một "bản sao lười biếng" trong tình huống này.

Tích hợp cũng cho phép Perforce thực hiện "bản sao lười" của tệp. Khi bạn chi nhánh tệp, máy chủ không thực sự chứa hai bản sao của tệp - nó chỉ giữ tệp nguồn và một con trỏ trong cơ sở dữ liệu ghi lại thực tế rằng chi nhánh tới tệp đích đã xảy ra. Bản sao lười biếng làm cho phân nhánh hoạt động trên không thấp; máy chủ không phải theo dõi các bản sao tệp trùng lặp.

Điều này làm cho nó có vẻ như phương pháp chi nhánh thưa thớt chỉ thêm khả năng lỗi của con người vào quá trình, ví dụ, nhà phát triển có thể bắt đầu làm việc trên một tệp mà họ không thêm vào chi nhánh thưa thớt và sau đó vô tình cập nhật thay đổi cho nhánh mục tiêu phá vỡ bản dựng. Tuy nhiên, chức năng phân nhánh thưa thớt tồn tại vì một lý do. Bất kỳ thông tin phản hồi về lý do tại sao nó tồn tại và lý do tại sao tôi nên sử dụng nó trên một chi nhánh tư nhân hoàn chỉnh (hoặc ngược lại) sẽ được đánh giá cao.

Answer 1

Như bạn đã lưu ý trong không gian tài liệu thực sự không phải là vấn đề. Tốc độ là mặc dù. Việc đồng bộ hóa toàn bộ cây phát triển có thể mất nhiều thời gian. Việc tích hợp lại cũng sẽ mất một thời gian. Nếu bạn chỉ cần một nhánh cây thì cả hai hoạt động này nhanh hơn nhiều.

Lỗi của con người, như bạn đã nói, có thể xảy ra, nhưng nếu bạn tạo một branchspec, nó có thể giúp giảm bớt một số lỗi tiềm ẩn.

Answer 2

Không gian đĩa đồng bộ hóa và tốc độ đồng bộ hóa là các vấn đề với việc tạo ra các nhánh đầy đủ (sao chép lười giúp trên máy chủ chứ không phải mạng hoặc ứng dụng khách). Tuy nhiên tôi thấy việc thiết lập và hiểu dễ dàng hơn là cố gắng tạo ra một nhánh thưa thớt, vì vậy các nhánh đầy đủ là những gì chúng ta sẽ sử dụng.

Answer 3

Một tình huống tốt mà phân nhánh thưa thớt phù hợp là khi bạn có một sản phẩm phức tạp có khả năng tạo thành nhiều mô-đun. Giả sử quá trình xây dựng mất một thời gian dài cho toàn bộ hệ thống và có lẽ quá trình đồng bộ mất một lúc - rất nhiều tệp dữ liệu. Nhưng sự phát triển của bạn chỉ cần sửa đổi một tập con nhỏ của toàn bộ cơ sở nguồn - có thể là một hoặc hai mô-đun, có thể có một số mã liên kết "cao hơn".

Trong trường hợp này, làm một nhánh thưa thớt có thể có nhiều ý nghĩa. Điều đó có nghĩa là bạn đã đồng bộ hóa với phần lớn nội dung và có thể cũng đã được tạo. Nhưng bạn phải cẩn thận rằng bất kỳ tập tin bạn sửa đổi được phân nhánh đầu tiên - nếu không bạn có nguy cơ phá vỡ đường chính. Chắc chắn nó đòi hỏi sự chăm sóc nhiều hơn bởi các lập trình viên.

Một trường hợp khác khi phân nhánh thưa thớt có thể là cách thực tế duy nhất để phát triển nhánh là khó có thể có nhiều phiên bản ứng dụng của bạn trên máy phát triển. Trong trường hợp này, sẽ rất khó khăn để có cả một xây dựng đường chính và xây dựng một tòa nhà phát triển và chạy song song. Rõ ràng là không lý tưởng, nhưng một số sản phẩm giống như vậy hoặc bằng sự cần thiết hoặc lịch sử.