2009-08-15 34 views
9

Vì vậy, tôi đã quen với điều này:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.htmlCách tốt nhất để xử lý các chi nhánh của chi nhánh nhà cung cấp trong SVN là gì?

Câu hỏi của tôi là làm thế nào để bạn xử lý một chi nhánh nhà cung cấp đó có cả phát hành ổn định và một chi nhánh alpha/beta mà bạn muốn tích hợp không?

Vì vậy, giả sử bạn làm theo ví dụ ban đầu từ sách SVN. Bạn muốn có:

svn: // localhost/home/svn/vendor/libcomplex/hiện
svn: //localhost/home/svn/vendor/libcomplex/1.0
svn: // localhost/home /svn/vendor/libcomplex/1.1 (giống như hiện tại)

Bây giờ, nói rằng bạn có hai phiên bản của riêng 'calc' ứng dụng của bạn:

calc (điều này chủ yếu là thân cây == calc 2.0)
calc -1.0 (phát hành ra công khai)

Giả sử sử dụng calc-1.0 libcomplex 1.0 và calc (trong thân cây) đã sử dụng libcomplex 1.1, vẫn đang được phát triển.

Có lỗi trong libcomplex 1.0 và phiên bản mới được phát hành để sửa lỗi đó: libcomplex 1.0.1. Các nhà duy trì libcomplex cũng đã đưa bugfix này vào libcomplex 1.1.

Bạn chưa sẵn sàng phát hành calc 2.0, vì vậy bạn cần tích hợp libcomplex 1.0.1 vào chi nhánh nhà cung cấp của bạn và sau đó cập nhật calc-1.0 để tạo bản sửa lỗi.

Nó sẽ đi đâu?

Bạn không thể đặt nó tại svn: // localhost/home/svn/vendor/libcomplex/hiện tại vì 1.1 hiện đang sống ở đó.

Bạn có sao chép svn: //localhost/home/svn/vendor/libcomplex/1.0 vào svn: //localhost/home/svn/vendor/libcomplex/1.0.1 và sau đó đưa vào bản phát hành mới không? Bằng cách đó bạn có thể sử dụng svn để hợp nhất sự khác biệt giữa 1,0 và 1.0.1 đến calc-1.0.

Trả lời

3

Thực tiễn được khuyến nghị là tạo chi nhánh cho bản phát hành của bạn. Bằng cách đó, nó không quan trọng những gì thay đổi bạn thực hiện trong thân cây để thư mục nhà cung cấp của bạn. Sau đó bạn có thể cập nhật nhánh phát hành 1.0 với phiên bản 1.0.1 của libcomplex, và điều đó sẽ không có thân cây bị ảnh hưởng (calc 2.0).

Điều này sẽ không hoạt động nếu calc 1.0 và calc 2.0 sống cạnh nhau trong cùng một nhánh.

Điều tiếp theo cần làm là không có "hiện tại". Chỉ cần tham khảo trực tiếp phiên bản bạn đang sử dụng. ví dụ: để cấu trúc thư mục của bạn là:

vendor/libcomplex/1.0 
vendor/libcomplex/1.1 
vendor/libcomplex/1.0.1 

và không bao giờ ghi đè các tệp này. Sau đó, calc 2.0 có thể tham chiếu đến phiên bản 1.1 của libcomplex và calc 1.0 có thể tham chiếu đến 1.0.1.

Tùy chọn cuối cùng của bạn, (và không thực sự được đề nghị), là sử dụng thẻ svn (xem complex tags). Chúng cho phép bạn trộn và ghép các phiên bản, vì vậy bạn có thể tạo một thẻ để đại diện cho bản phát hành bản vá của calc 1.0 với phiên bản libcomplex cũ.

+0

Trong ví dụ trước, tôi có một nhánh cho bản phát hành của tôi: calc 1.0. Thư mục của nhà cung cấp không được chứa trong calc. Bạn có gợi ý rằng/nhà cung cấp được phân nhánh không? Để rõ ràng ở đây là ví dụ tôi mô tả: /vendor/libcomplex/ /calc/trunk/ /calc/branches/1.0/ Đề xuất của bạn không sử dụng "hiện tại" và chỉ sử dụng cấu trúc thư mục sẽ không cho phép hợp nhất các thay đổi giữa các phiên bản thành thân cây, do đó sẽ đánh bại mục đích. Bạn cần lịch sử thay đổi này để cho phép hợp nhất các thay đổi vào thân cây nơi bạn đã sửa đổi nguồn nhà cung cấp ban đầu. –

+0

Cách tiếp cận của tôi là dành cho công việc khi tất cả những gì bạn đang làm là sử dụng các phiên bản đã phát hành. Nếu bạn cũng đang sửa đổi nguồn, thì có thể hữu ích khi xử lý mã của nhà cung cấp làm mã của riêng bạn (ví dụ bao gồm mã trong nhánh thân chứ không phải nhà cung cấp dưới dạng thư mục riêng). Tuy nhiên, cách tiếp cận của bạn cũng có ý nghĩa. Tạo chi nhánh nhà cung cấp/libcomplex/1.0.1, hợp nhất mọi tùy chỉnh và cập nhật bản phát hành calc 1.0 để trỏ tới nhà cung cấp/libcomplex/1.0.1, sau đó phát hành calc 1.0.1. Bất cứ khi nào libcomplex 1.1 đã sẵn sàng, hãy hợp nhất các tùy chỉnh, xây dựng calc2.0 và bạn tốt để đi. Trunk không bao giờ trỏ đến 1.0.1 –

2

Ý tưởng đằng sau nhánh của nhà cung cấp dường như là họ nên phản ánh kho lưu trữ của nhà cung cấp có thể trông như thế nào.Vì vậy, current đại diện cho thân cây của nhà cung cấp và các phiên bản được gắn thẻ đại diện cho các thẻ của nhà cung cấp, được tạo khi mỗi phiên bản được phát hành.

Với điều này, câu trả lời cho câu hỏi trở nên khá rõ ràng. Để phát hành 1.0, 1.1 và sau đó là 1.0.1, nhà cung cấp có lẽ có một nhánh cho 1.0.x phiên bản lỗi trong khi tiếp tục hoạt động trên phiên bản 1.1 và phiên bản mới hơn trên thân cây của họ. Chi nhánh nhà cung cấp của chúng tôi phải phản ánh thiết lập này.

Tức là, chúng tôi cũng cần một chi nhánh (trong chi nhánh nhà cung cấp của chúng tôi) cho các phiên bản 1.0.x bị lỗi. Điều này sẽ được tạo từ hiện tại tại thời điểm chứa 1.0 và có thể được đặt tên là current-1.0.x. Chi nhánh này sau đó có thể được cập nhật để giữ 1.0.1, sau đó có thể được gắn thẻ và sao chép vào cây của chúng ta như bình thường.

2

tôi làm việc như thế này với các thư viện bên ngoài:

project/myProject/{branches,trunk} 
vendor/libcomplex/1.0 
vendor/libcomplex/1.0.1 
vendor/libcomplex/2.0.0 
mypatched-vendor/libcomplex/1.0 
mypatched-vendor/libcomplex/1.0.1 
mypatched-vendor/libcomplex/2.0.0 

đâu vendor/<lib>/<version> không bao giờ được thay đổi sau khi nhập khẩu và mypatched nhà cung cấp được bắt đầu với svn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version>.

Bây giờ diffing vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0 sẽ cung cấp cho bạn các bản vá được hợp nhất vào phiên bản 1.0.1 vừa nhập.

Tôi có thể thuộc thiểu số, nhưng tôi thích các thuộc tính svn:externals. Rất nhiều IDE không thích chúng nên sử dụng theo ý mình. Lý do là vậy. Giờ đây, tôi có thể chỉnh sửa dự án chính của mình:

checkout project/myProject/trunk to myprj-trunk khi bạn thanh toán.

svn propedit svn:externals . 
# with 
libcomplex URLTO/mypatched-vendor/libcomplex/1.0 

Khi tôi muốn thử nghiệm phiên bản lib mới, tôi chỉ cần chỉnh sửa thuộc tính đó đến địa điểm khác và chạy cập nhật. Điều này cũng có tác dụng mà tôi không vô tình cam kết bất cứ điều gì để libcomplex một phần của cây ngay cả khi tôi đã thay đổi một số tập tin trên WC. Tôi phải ở dưới thư mục đó hoặc đặc biệt cam kết thay đổi ở đó.

Giờ đây, việc nâng cấp, sửa lỗi, các nhánh của dự án của tôi có thể dễ dàng được chuyển sang các phiên bản libcomplex mới mà không có nhiều hơn so với kết hợp ban đầu với nhà cung cấp dịch vụ của tôi. Tất cả các nhánh dự án của tôi chỉ cần trao đổi và kiểm tra. Ngoài ra nó tương đối dễ dàng để có được phụ thuộc thư viện cho các dự án của tôi IMHO. Điều tuyệt vời nhất về externals là khi bắt đầu một dự án mới và ngược dòng cũng được phát triển và sử dụng svn, bạn có thể tham chiếu ngược dòng như bên ngoài nếu bạn không cần phải vá thư viện đó. Và khi ngược dòng phá vỡ dự án của bạn, bạn có thể giữ phiên bản ngược dòng trong một thời gian với các tùy chọn -rNUM như:

libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk 

Một nhược điểm nhất định để svn: externals là url externals có để có thể truy cập với cùng URI từ tất cả các thanh toán các biến thể của dự án của bạn.

Nhưng sử dụng externals cho phép bạn để giữ nhà cung cấp repo riêng biệt từ dự án repo của bạn.

Các vấn đề liên quan