2010-04-02 32 views
7

Có thể hợp nhất một loạt các sửa đổi từ một chi nhánh này sang chi nhánh khác trong Mercurial không?sáp nhập các sửa đổi đã chọn từ một chi nhánh này sang chi nhánh khác trong Mercurial

ví dụ:

|r1 
|r2 
|r3 
|\___ 
| | r5 
| | r6 
| | r7 
| | ... 
| | r40 
|r41 

Nếu tôi muốn hợp nhất sửa đổi 6 & 7, nhưng không phải 5, vào nhánh chính - điều này có thể?

một hợp nhất như vậy có thể là tầm thường, ví dụ, nếu r5 chỉnh sửa file mà không được sửa đổi trong 6 & 7 (và do đó thay đổi nó, nếu không cần thiết, có thể một cách an toàn bị bỏ qua)

gì về nhiều phiên bản được chọn nằm trong khoảng từ chi nhánh A đến chi nhánh B? ví dụ. hợp nhất 4-7, 20-25 và 30-34?

(đây không phải là một trường hợp thực tế, chỉ cần một minh hoạ. Tôi đang cố gắng để hiểu nếu hg có merge này tính năng điều chỉnh tầm xa mà tôi biết svn có)

Trả lời

7

Câu trả lời đơn giản là không.

Điều này trái với tinh thần của Mercurial.

Biểu đồ của bạn ngụ ý rằng 6 phụ thuộc vào 5 vì vậy, mọi thứ kéo 6 cũng nên tránh 5 nếu không nó sẽ không có ý nghĩa.

Dường như với tôi rằng bạn đã nhầm Mercurial ở đây. Nếu cây thay đổi của bạn là tuyến tính, nó thường là một dấu hiệu cho thấy bạn đang sử dụng Mercurial như bạn sẽ sử dụng CVS hoặc SVN.

cây Thay đổi của bạn sẽ trông như thế hơn:

4 
/\ 
/| |\ 
/| | \ 
5 7 23 \ 
| | | 25 
6 8 24 | 
     26 

Và sau đó bạn có thể kéo một trong hai chi nhánh bắt đầu từ 5 hoặc một bắt đầu từ 23.

Bây giờ, sai lầm là con người, do đó, có một "cơ sở" được gọi là xuất khẩu, cho phép bạn tạo một tệp diff đơn giản từ một changeset.

Trong trường hợp cụ thể của bạn, bạn sẽ như sau:

  • bản sao kho lên đến r4
  • tạo ra một diff từ r6 và một từ r7 (xuất khẩu)
  • áp dụng cả hai (theo thứ tự) trên bản sao mới (nhập)
  • chạy thử nghiệm đơn vị của bạn cho đến khi chúng vượt qua
  • cam kết
  • kéo trong r41
  • merge
  • chạy thử nghiệm đơn vị của bạn cho đến khi họ vượt qua
  • cam

Nếu bạn muốn, bạn cũng có thể đi con đường mở rộng. Có một số phần mở rộng hữu ích cho thao tác các changesets. Một tập hợp mẫu:

Ở đây bạn có thể ví dụ clone kho (quan trọng, luôn luôn kiểm tra này trên máy nhái, chỉ trong trường hợp) và sau đó sụp đổ những rặng bạn quan tâm Sau đó, bạn có thể xuất/nhập chúng.

+0

Không đúng là r6 phải phụ thuộc vào r5 theo bất kỳ cách nào có ý nghĩa. Ví dụ: có thể r5 chỉ thay đổi một số tệp mà các bản sửa đổi khác không chạm vào, do đó, hoàn toàn không có vấn đề bỏ qua bản sửa đổi cụ thể đó (từ quan điểm trung tâm dữ liệu). Xin đừng cho rằng tôi đang sử dụng hg theo cách này, tôi chỉ cố gắng hiểu khả năng của nó. –

+0

Ngoài ra, tôi đã không hoàn toàn có được những gì bạn có nghĩa là bằng cách nhìn cây _should_. Hình minh họa cây của bạn hiển thị nhiều nhánh với vài sửa đổi. Đó có phải là tinh thần của hg - chỉ có những nhánh ngắn? Bởi vì đôi khi bạn chỉ cần một nhánh riêng biệt để thực hiện rất nhiều công việc mà không đi vào thân cây. Nếu bạn duy trì nhiều phiên bản lịch sử, nó không khả thi để có một kho lưu trữ trên mỗi phiên bản, do đó, các nhánh là giải pháp hợp lý duy nhất. Vì vậy, làm thế nào để bạn đề nghị để giữ cho các chi nhánh ngắn, và tại sao nó sẽ tốt hơn so với việc có nhiều chi nhánh khác nhau khi cần thiết? –

+0

r6 phụ thuộc vào r5 bởi vì bạn nói nó đã làm khi bạn thực hiện r5 r6 của cha mẹ. Nếu bạn muốn tránh điều đó, và chúng thực sự không liên quan, bạn có thể 'hg update' cho một phụ huynh khác trước khi thực hiện thay đổi 6. Nếu trước khi thực hiện r6 bạn đã thực hiện 'hg update r4' thì cha mẹ của r6 sẽ là R4, và bạn có thể di chuyển nó đến bất kỳ nhánh phát triển nào đã có r4. Theo nghĩa rộng nhất khi thực hiện thay đổi, hãy tự hỏi "điểm sớm nhất trong lịch sử tôi có thể thực hiện việc này" và sau đó là 'cập nhật hg' cho điểm đó. Sau đó, bạn có một changeset có thể dễ dàng sáp nhập bất cứ nơi nào nó có ý nghĩa. –

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