2012-03-02 27 views
5

Tôi có một kho chứa thủy ngân với hai nhánh cố định, mặc định và UAT. Thỉnh thoảng, chúng tôi triển khai (quảng bá) một phiên bản mới của ứng dụng của chúng tôi cho môi trường UAT và chúng tôi thực hiện điều này bằng cách hợp nhất một cam kết mặc định ổn định cho nhánh UAT. Đôi khi mọi thứ sẽ được sửa lỗi trong nhánh UAT và các sửa lỗi này sẽ được hợp nhất trở lại mặc định.Mercurial: Chi nhánh các thay đổi cụ thể tiếp tục quay trở lại sau khi kết hợp giả

Trên nhánh UAT, tôi cần thay đổi một vài thứ cho mục đích triển khai - chuỗi kết nối và các cài đặt môi trường khác nhau. Những gì tôi đã cố gắng làm là thực hiện những thay đổi này trong nhánh UAT và cam kết chúng (tất cả là một cam kết) ngay sau khi hợp nhất mặc định thành UAT. Tôi sau đó giả mạo sáp nhập này cam kết trở lại mặc định - suy nghĩ là vì mặc định bây giờ có cam kết này trong tương lai tổ tiên của nó bugfix sáp nhập từ UAT vào mặc định sẽ không cố gắng làm lại những thay đổi cụ thể UAT.

Tuy nhiên mọi thứ đã không diễn ra suôn sẻ như tôi đã hy vọng. Bắt đầu với những giả-sáp nhập cam kết vào mặc định, tôi đã thử cả hai kịch bản sau đây:

1) Make a few more commits to default and then "promote" to UAT (merge default onto UAT) 
2) Make a bugfix on UAT and "backport" it to default (merge UAT onto default) 

Giữa chạy # 1 và # 2 Tôi đã bị tước tất cả mọi thứ ra để cả hai kịch bản bắt đầu từ cùng một điểm .

Điều tôi thấy là tùy thuộc vào hướng cuối cùng được hợp nhất, tôi vẫn cần kiểm tra các tệp đã thay đổi sau khi thực hiện một hoặc hợp nhất và hoàn nguyên khác - đôi khi hợp nhất cố gắng đặt cấu hình mặc định vào UAT và đôi khi là UAT cấu hình thành hợp nhất.

Nếu tôi hoàn nguyên các thay đổi cấu hình và cam kết hợp nhất, sau đó việc hợp nhất trong tương lai sẽ hoạt động đúng, nhưng phút tôi đi theo hướng khác, hợp nhất lại đặt cấu hình sai vào tệp.

Tôi đang thiếu gì?

Trả lời

5

Tôi tin rằng vấn đề tương tự như vấn đề trong this question: việc hợp nhất không hoạt động theo cách bạn nghĩ rằng nó hoạt động. Hợp nhất chỉ là một câu hỏi so sánh các trạng thái tệp, đó là không phải là một vấn đề áp dụng các thay đổi từ một nhánh này sang nhánh khác.

điểm khởi đầu của bạn là một lịch sử như thế này:

UAT:  ... x --- y --- z 
          \ 
default: ..... a --- b --- c 

nơi xy chứa các thiết lập cấu hình cho UAT và b là merge giả không có các thiết lập cấu hình. Vì vậy, các tệp trong b trông giống như chúng đã thực hiện trong a - chúng đã được kết hợp giả.

Nếu bây giờ bạn thực hiện một sự thay đổi mới trên default mà bạn muốn quảng cáo để UAT, bạn sẽ làm việc với:

UAT:  ... x --- y 
        \ 
default: ..... a --- b --- c 

Các hợp nhất là giữa yc. Đó là một sự hợp nhất thoái hóa nơi tổ tiên chung là y. Điều này có nghĩa là tất cả thay đổi giữa bc sẽ "giành được" trong quá trình hợp nhất ba chiều. Bảng bao hunks được hợp nhất theo một ba chiều merge là:

ancestor local other -> merge 
old  old old  old (nobody changed the hunk) 
old  old new  new (they changed the hunk) 
old  new old  new (you changed the hunk) 
old  new new  new (hunk was cherry picked onto both branches) 
old  foo bar  <!> (conflict, both changed hunk but differently) 

Lưu ý rằng kết quả hợp nhất không phụ thuộc vào sự "chỉ đạo" của việc hợp nhất: bảng là đối xứng đối với local và với other cột.Tại đây, cả hai số ancestorlocalyotherc. Vì vậy, bàn trở thành:

ancestor local other -> merge 
old  old new  new (they changed the hunk) 

Bạn có thể thấy rằng kết quả hợp nhất luôn chứa sự thay đổi new đã được thực hiện trong c.

Điều quan trọng là hợp nhất bị thoái hóa. Giả sử bạn có một cam kết mới trên UAT và cam kết này không chạm vào các chuỗi cấu hình, thì bạn sẽ nhận được cùng một hành vi khi bạn hợp nhất (theo một trong hai hướng, các phép trộn là đối xứng).

Giải pháp bình thường cho sự cố này là để ngoại vi hóa chuỗi cấu hình. Đặt chúng ở đâu đó ngoài kiểm soát phiên bản - biến môi trường, tệp cấu hình không phiên bản, v.v. Nếu bạn có thể, hãy đặt tệp cấu hình dưới sự kiểm soát phiên bản dưới dạng mẫu . Sau đó bạn tạo một tệp cấu hình không phiên bản cho nhánh UAT bao gồm tệp cấu hình được kiểm soát phiên bản. Bạn ghi đè cài đặt khi cần trong tệp cấu hình không phiên bản này.

+0

Trong ngắn hạn, tôi bị hạn chế để người duy trì triển khai ứng dụng của mình theo cách thủ công từ máy của anh ấy. Anh ấy chỉ có một bản sao vì nó là một ứng dụng web cũ hơn và thay đổi các thiết lập thư mục IIS là một nhiệm vụ. Tôi thực sự muốn cho phép anh ấy sử dụng quy trình làm việc mà tất cả những gì anh ấy cần làm là hợp nhất từ ​​mặc định, xây dựng lại và triển khai, với khả năng di chuyển các bản sửa lỗi trở về mặc định cho các bản phát hành sau. Nếu tôi không bao giờ hợp nhất UAT trở lại mặc định, nhưng thay vào đó cấy lại các sửa lỗi, tôi nghĩ rằng nó sẽ hoạt động đúng không? Điều này trở thành một vấn đề mặc dù nếu có rất nhiều cam kết sửa lỗi ... –

+0

Có lẽ bạn chỉ có thể cho phép các thiết lập UAT được cam kết (để dễ dàng bảo trì) và sau đó sửa đổi (nhưng không cam kết) cục bộ? Bạn sẽ cần phải thay đổi các thay đổi trước khi hợp nhất và sử dụng '-X' để loại trừ chúng khi cam kết ([loại trừ phần mở rộng] (https://bitbucket.org/aragost/exclude) có thể giúp một chút). –

+0

Đó là cơ bản những gì anh ta đang làm tại thời điểm này - kệ và unshelving khi cần thiết. Thật không may là nó không liền mạch, và khi chúng ta thêm nhiều môi trường hơn (ví dụ như sản xuất) thì anh ta phải đối phó với nhiều kệ hoặc mq, không lý tưởng (nơi 'lý tưởng' là luồng công việc rõ ràng không thể giải thích được mà tôi mô tả ở trên :)). Tôi đoán chúng tôi sẽ thử cách tiếp cận cấy ghép cho bây giờ và xem làm thế nào mà đi ... –

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