Sử dụng Subversion Không có Thân cây

Question

Nhóm của tôi gần đây đã quyết định không sử dụng nhánh "thân cây" vốn là điển hình của hầu hết các bố cục kho lưu trữ subversion. Chúng tôi thấy rằng tại bất kỳ thời điểm nào, luôn luôn có một nhánh cụ thể hoạt động trong vai trò truyền thống mà thân cây sẽ giữ trong các kho lưu trữ khác. Tức là, chúng tôi luôn có một nhánh được đánh số cao nhất đại diện cho bản phát hành tiếp theo mà chúng tôi đang thực hiện. Vì vậy, một hợp nhất để thân cây chỉ đơn giản là thừa, vì vậy chúng tôi đã thoát khỏi thân cây.

Có ai khác ngoài kia làm việc này không?

Nếu có, bạn có nhận thấy bất kỳ ưu điểm/nhược điểm nào không?

Ngay cả khi nhóm của bạn không làm điều này, có ai có bất kỳ suy nghĩ nào về bố cục này không?

Answer 1

Bạn đang nói về tờ giấy Promotional Model - Tài liệu của Perforce nêu bật các vấn đề với nó - truyền đạt vai trò thay đổi của các dòng mã và di chuyển giữa các nhánh.

Việc mở rộng trên quan điểm của tôi về vấn đề niêm yết:

1) Thay đổi chính sách của mã dòng:

Mỗi dòng mã có một chính sách, cho dù nó được viết xuống và chính thức hóa, hoặc hoàn toàn ẩn trong một đầu của nhà phát triển. Nó định nghĩa ví dụ:

• ai được phép cam kết mã dòng
• bao nhiêu thử nghiệm là cần thiết (ví dụ làm đơn vị kiểm tra phải vượt qua, kiểm tra hồi quy, đầy đủ kiểm tra hệ thống)
• có bao nhiêu người phải xem xét mã thay đổi
• những loại thay đổi được phép

Với cách tiếp cận thân cây, các chính sách vẫn cố định, do đó dễ viết hơn, giúp chúng dễ dàng giao tiếp hơn (quan trọng hơn trong một nhóm lớn hơn).

ví dụ:Trunk:

• bất kỳ nhà phát triển có thể cam kết
• bất kỳ sự thay đổi
• kiểm tra đơn vị phải vượt qua
• xem xét mã sau khi cam kết

Version chi nhánh:

• chỉ phát triển duy trì
• chỉ lỗi sửa chữa
• đơn vị kiểm tra + hồi quy kiểm tra
• đang xem xét lại bởi 2 nhà phát triển khác trước khi cam kết

chi nhánh Tag:

• không cam kết sau khi tạo

phát triển của cá nhân chi nhánh:

• Chỉ kiểm tra nhà phát triển trong
• Bất kỳ sự thay đổi
• kiểm tra chỉ cần thiết trước khi sáp nhập vào thân cây
• xét Mã trước khi hợp nhất để thân cây

Nếu bạn có mô hình khuyến mãi, sau đó bạn có một chính sách trong khi phát triển chính, sau đó phải nói với mọi người khi bạn thay đổi chính sách trong khi chuẩn bị phát hành, sau đó một chính sách khác (cho dòng mã) sau khi dòng được phát hành.

Mô hình quảng cáo là một mô hình dễ dàng để tham gia, nó ánh xạ trực tiếp lên cách thức kiểm soát không phải là nguồn làm việc. Nhưng nó đau khi bạn bắt đầu nhận được các đội lớn.

Nếu bạn nhìn vào sự phát triển hạt nhân Linux, bạn có thể thấy sự căng thẳng giữa mô hình Khuyến mại và mô hình Trunk: Cây Linus là Quảng cáo - nó đi qua các chu kỳ giữa cửa sổ hợp nhất và thời gian ổn định. Nhưng Linux-tiếp theo và -mm đã nổi lên để cung cấp cho một thân cây giống như dòng.

SCM/VCS phân tán có phần khác nhau, các chính sách không phải được phân phối cho tất cả các nhà phát triển vì mỗi phát triển đều có cây riêng và kéo thay đổi khi muốn.

Dự án mã nguồn mở gặp phải sự cố là chúng không thể buộc mọi người thực hiện công việc vất vả để ổn định bản phát hành, sau khi phân nhánh từ thân cây. Do đó mô hình khuyến mãi quan trọng hơn như là một cách để thúc đẩy các nỗ lực ổn định, thay vì chỉ làm việc trên các tính năng.

2) Di chuyển công việc:

Một nhà phát triển có thể làm việc trên một tính năng mà chính sách cho dòng anh ấy làm việc trên những thay đổi để sửa lỗi mà thôi, ông bây giờ cần phải chuyển bản sao làm việc của mình để một số- khác nhau hàng. Đây có thể là bất cứ nơi nào từ dễ đến vô cùng khó khăn tùy thuộc vào hệ thống SCM đang sử dụng. Vấn đề này không xảy ra nếu nhà phát triển đang làm việc trên thân cây, vì công việc của họ luôn đi vào thân cây.Nếu nhà phát triển ở trên một nhánh riêng hoặc tính năng thì công việc của họ sẽ chỉ tác động lên thân cây (và bản phát hành).

Nếu tính năng đã được đăng ký nhưng bị trì hoãn từ phiên bản hiện tại, bạn phải tìm cách xóa nó. Vấn đề này vẫn còn tồn tại với mô hình thân cây, nhưng có thể dễ dàng hơn một chút để giải quyết - những thứ nhặt hoa anh đào từ thân cây cho bản phát hành. Đây là nơi các nhánh tính năng trợ giúp - nhưng chúng có chi phí tích hợp.

Answer 2

Subversion cho phép cả hai cách tiếp cận. Thân cây không phải là điều cần thiết mà là một quy ước. Nếu bạn có nó, một số công cụ làm việc dễ dàng hơn (ví dụ như các công cụ di chuyển cho Git). Nếu bạn không có nó, bạn phải làm một số thứ bằng tay nhưng tôi không thể nghĩ ra điều gì đó mà bạn sẽ nhận thấy trong công việc hàng ngày của bạn.

Answer 3

Chúng tôi thực hiện - sắp xếp. Chúng tôi không sử dụng một thân cây, nhưng tạo ra một chi nhánh mới cho mỗi bản phát hành của các dự án của chúng tôi. Chi nhánh 'được gắn thẻ' này sau đó là thân cây cho mỗi phiên bản và chúng tôi sẽ sửa lại các bản sửa lỗi bằng cách hợp nhất các thay đổi vào các phiên bản cũ hơn.

Nó hoạt động tốt cho chúng tôi, nhưng chúng tôi có rất nhiều tiểu dự án trong dự án của chúng tôi.

Answer 4

Gần đây tôi đã bắt đầu làm việc trên một dự án trên kho lưu trữ lật đổ. Bất kỳ ai tạo kho lưu trữ không theo bất kỳ bố cục cụ thể nào - chúng chỉ đơn giản là nhồi tất cả mọi thứ vào thư mục gốc của kho (không có trunk /, no branch /, và chắc chắn không có thẻ /). Tôi muốn tạo một chi nhánh để làm việc và một số thẻ cho các công cụ khác, nhưng nhận ra khó khăn như thế nào để làm điều đó trên một kho lưu trữ subversion mà không theo một bố trí thích hợp.

Answer 5

IME, trong một số môi trường, thân cây là nơi tốt để trao đổi các bản sửa lỗi và thay đổi từ/đến. Tức là, mọi người hợp nhất các bản sửa lỗi của mình thành thân cây và mọi người kết hợp các bản sửa lỗi của người khác từ thân cây. Chúng tôi thấy rằng rất hữu ích trong một môi trường có nhiều mã được chia sẻ giữa nhiều dự án độc lập và nơi tất cả các dự án đó đóng góp vào mã được chia sẻ.

Mặc dù vậy, môi trường của bạn có thể khác.

Answer 6

Vấn đề của tôi với giấy Perforce là nó xóa bỏ mô hình quảng cáo mà không đề cập đến lợi thế chính, giảm chi phí hợp nhất đã giảm. Trong thực tế, bài báo sai quy định rằng "mô hình đường chính" áp đặt "không có thêm phí hành chính", một tuyên bố lố bịch. Mô hình "luôn hợp nhất vào thân cây" có nghĩa là - bạn có toàn bộ chi phí của mọi người phải hợp nhất. Đây là chi phí vô nghĩa nếu bạn có tình huống sau (chúng tôi có):

a) một nhóm nhỏ (5 đến 7 nhà phát triển) tất cả đều nằm trong khoảng cách la hét của nhau. giao tiếp là một vấn đề không khi chúng ta cần phải tạo ra một ngành

và

b) một codebase nơi có bao giờ thực sự chỉ có 2 chi nhánh lớn - một chi nhánh sản xuất và "điều tiếp theo trong sự phát triển". Có lẽ một lần trong một mặt trăng màu xanh, chúng tôi có 3.

Tôi đoán quan điểm của tôi là - đó là một điều tình huống. Để nói "mô hình quảng cáo có vấn đề" giống như nói "không bao giờ sử dụng OR/M". Nó phụ thuộc vào môi trường của bạn.