Tại sao tôi nhận được xung đột cây trong Subversion?

Tôi đã có một nhánh tính năng của thân cây của mình và đã hợp nhất các thay đổi từ thân cây của tôi vào nhánh của tôi theo định kỳ và mọi thứ đều hoạt động tốt. Hôm nay tôi đã hợp nhất chi nhánh trở lại vào thân cây và bất kỳ tệp nào được thêm vào thân cây của tôi sau khi tạo chi nhánh của tôi được gắn cờ là "xung đột cây". Có cách nào để tránh điều này trong tương lai?

Tôi không nghĩ rằng những điều này đang được gắn cờ đúng.

Tôi tìm thấy giải pháp đọc liên kết mà Gary đưa ra (và tôi đề nghị làm theo cách này).

Tóm tắt để giải quyết xung đột cây cam kết thư mục làm việc của bạn với máy khách SVN 1.6.x bạn có thể sử dụng:

svn resolve --accept working -R .

đâu .là thư mục trong xung đột.

CẢNH BÁO : "Cam kết thư mục làm việc của bạn" có nghĩa là cấu trúc hộp cát của bạn sẽ là cấu trúc bạn đang cam kết, vì vậy, ví dụ, nếu bạn đã xóa một số tệp khỏi hộp cát của mình, chúng cũng sẽ bị xóa khỏi kho lưu trữ. Điều này chỉ áp dụng cho thư mục xung đột.

Theo cách này, chúng tôi đang đề nghị SVN giải quyết xung đột ( --resolve), chấp nhận bản sao làm việc bên trong hộp cát của bạn ( --accept working), đệ quy ( -R), bắt đầu từ thư mục hiện tại ( .).

Trong TortoiseSVN, chọn "Đã giải quyết" khi nhấp chuột phải, thực sự giải quyết được vấn đề này.

Subversion 1.6 đã thêm Xung đột cây để che xung đột ở cấp thư mục. Một ví dụ điển hình là khi bạn xóa cục bộ một tệp thì một bản cập nhật sẽ cố gắng thay đổi văn bản trên tệp đó. Một cách khác là khi bạn có một lật đổ Đổi tên một tệp bạn đang chỉnh sửa vì đó là hành động Thêm / Xóa.

Blog lật đổ của CollabNet có một bài viết tuyệt vời về Xung đột cây .

Theo kinh nghiệm của tôi, SVN tạo ra một xung đột cây KHI tôi xóa một thư mục. Dường như không có lý do.

Tôi là người duy nhất làm việc với mã của tôi -> xóa thư mục -> cam kết -> xung đột!

Tôi không thể chờ để chuyển sang Git .

Tôi nên làm rõ - Tôi sử dụng Subclipse . Đó có lẽ là vấn đề! Một lần nữa, tôi không thể chờ để chuyển ...

Tôi không biết điều này có xảy ra với bạn không, nhưng đôi khi tôi chọn thư mục sai để hợp nhất và tôi gặp lỗi này mặc dù tất cả các tệp xuất hiện hoàn toàn tốt.

Thí dụ:

Hợp nhất / svn / Dự án / chi nhánh / một số chi nhánh / Nguồn tới / svn / Dự án / trung kế ---> Xung đột cây

Hợp nhất / svn / Dự án / chi nhánh / một số chi nhánh thành / svn / Dự án / trung kế ---> OK

Đây có thể là một sai lầm ngu ngốc, nhưng nó không phải lúc nào cũng rõ ràng bởi vì bạn nghĩ nó là một cái gì đó phức tạp hơn.

Điều gì đang xảy ra ở đây là như sau: Bạn tạo một tệp mới trên thân cây của mình, sau đó bạn hợp nhất nó vào nhánh của bạn. Trong hợp nhất cam kết, tập tin này cũng sẽ được tạo trong chi nhánh của bạn.

Khi bạn hợp nhất nhánh của bạn trở lại vào thân cây, SVN sẽ cố gắng làm lại như sau: Nó thấy rằng một tệp đã được tạo trong nhánh của bạn và cố gắng tạo nó trong thân cây của bạn trong cam kết hợp nhất, nhưng nó đã tồn tại! Điều này tạo ra một cuộc xung đột cây.

Cách để tránh điều này, là thực hiện một sự hợp nhất đặc biệt, tái hòa nhập . Bạn có thể đạt được điều này với công --reintegratetắc.

Bạn có thể đọc về điều này trong tài liệu: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Tuy nhiên, khi hợp nhất nhánh của bạn trở lại thân cây, toán học cơ bản hoàn toàn khác. Chi nhánh tính năng của bạn bây giờ là một sự nhầm lẫn của cả thay đổi thân cây trùng lặp và thay đổi nhánh riêng, do đó, không có phạm vi sửa đổi tiếp giáp đơn giản nào để sao chép. Bằng cách chỉ định tùy chọn --reintegrate, bạn đang yêu cầu Subversion sao chép cẩn thận chỉ những thay đổi duy nhất cho chi nhánh của bạn. (Và trên thực tế, nó thực hiện điều này bằng cách so sánh cây thân cây mới nhất với cây nhánh mới nhất: sự khác biệt kết quả chính xác là sự thay đổi nhánh của bạn!)

Sau khi tái hòa nhập một chi nhánh, rất nên loại bỏ nó, nếu không, bạn sẽ tiếp tục nhận được treeconflicts bất cứ khi nào bạn hợp nhất theo hướng khác: từ thân cây đến chi nhánh của bạn. (Vì lý do chính xác giống như mô tả trước đây.)

Có một cách xung quanh điều này quá, nhưng tôi chưa bao giờ thử nó. Bạn có thể đọc nó trong bài viết này: Tái hòa nhập chi nhánh Subversion trong v1.6

Điều này có thể được gây ra bởi việc không sử dụng cùng một phiên bản máy khách.

Sử dụng máy khách phiên bản 1.5 và máy khách phiên bản 1.6 đối với cùng một kho lưu trữ có thể tạo ra loại vấn đề này. (Tôi chỉ tự cắn mình.)

Nếu bạn gặp phải xung đột cây không có ý nghĩa vì bạn đã không chỉnh sửa / xóa / đến bất kỳ nơi nào gần tệp, thì cũng có khả năng xảy ra lỗi trong lệnh hợp nhất.

Điều có thể xảy ra là trước đây bạn đã hợp nhất một loạt các thay đổi bạn đang đưa vào trong hợp nhất hiện tại của bạn. Chẳng hạn, trong thân cây ai đó đã chỉnh sửa một tệp, và sau đó đổi tên nó. Nếu trong lần hợp nhất đầu tiên của bạn, bạn bao gồm chỉnh sửa, và trong lần hợp nhất thứ hai bao gồm cả chỉnh sửa và đổi tên (về cơ bản là xóa), nó cũng sẽ tạo cho bạn một xung đột cây. Lý do cho điều này là bản chỉnh sửa được hợp nhất trước đó xuất hiện dưới dạng của riêng bạn và do đó việc xóa sẽ không được thực hiện tự động.

Điều này có thể xảy ra trên 1,4 kho lưu trữ ít nhất, tôi không chắc liệu việc sáp nhập được giới thiệu trong 1.5 có giúp ích gì ở đây không.

Cho đến ngày hôm nay, trong ít nhất 3 tháng trước, tôi thường xuyên gặp phải hàng trăm xung đột cây khi cố gắng hợp nhất một nhánh trở lại vào thân cây (sử dụng TortoiseSVN 1.11 ). Dù có nổi loạn hay không, BTW. Tôi đã sử dụng TortoiseSVN kể từ phiên bản v1, vào năm 2004 và tôi đã từng tái hòa nhập các chi nhánh mọi lúc. Một cái gì đó đã xảy ra gần đây tôi cho rằng?

Vì vậy, hôm nay tôi đã chạy thử nghiệm đơn giản này và tôi đã tìm thấy những gì đang tạo ra những xung đột điên rồ này:

1. Tôi rẽ khỏi thân cây @ 393;
2. Tôi đã sửa đổi hàng chục tệp một cách ngẫu nhiên, cũng như tạo các tệp mới;
3. Tôi cam kết. Bây giờ @ 395 (một đồng nghiệp đã rẽ nhánh ở 394 để thực hiện công cụ của riêng mình).
4. Sau đó, tôi đã cố gắng tái hòa nhập chi nhánh trở lại vào thân cây, chỉ kiểm tra; theo khuyến nghị của TortoiseSVN trong trình hướng dẫn: "để hợp nhất tất cả các sửa đổi (tái hòa nhập), để trống ô đó". Để đạt được điều này, tôi nhấp chuột phải vào thư mục trung kế và chọn "TortoiseSVN> Hợp nhất, từ / path / đến / chi nhánh" và tôi để trống phạm vi rev , như được khuyên trên hộp thoại.

Thảo luận: (xem phần đính kèm)

tất cả các sửa đổi ... của những gì? Tôi ít biết rằng khách hàng chắc hẳn đã đề cập đến " tất cả các sửa đổi của mục tiêu! (Thân cây)", vì, trong quá trình tái hòa nhập chi nhánh đó, tôi đã thấy đề cập đến "Sáp nhập sửa đổi 1-ĐẦU"! CHÚA ƠI. Ác quỷ đáng thương, bạn đang rơi vào cái chết của bạn ở đây. Chi nhánh đó được sinh ra @ 393, bạn không thể đọc giấy khai sinh của mình, vì Chúa sao?

Nghị quyết:

1. Trái với những gì được khuyên bởi wiz, hãy chỉ định một phạm vi, bao gồm TẤT CẢ các phiên bản của ... cuộc sống của chi nhánh! do đó, 394-ĐẦU ;
2. bây giờ chạy thử nghiệm hợp nhất đó một lần nữa và lấy một điếu xì gà. ( ).

Về mặt đạo đức: Tôi không thể hiểu tại sao họ vẫn không sửa lỗi đó, vì đó là một lỗi, tôi xin lỗi. Tôi nên dành thời gian để báo cáo điều này với họ.

Hôm nay tôi cũng gặp phải vấn đề này, mặc dù vấn đề cụ thể của tôi có lẽ không liên quan đến bạn. Sau khi kiểm tra danh sách các tập tin, tôi nhận ra những gì tôi đã làm - tôi đã tạm thời sử dụng một tập tin trong một tập hợp từ tập hợp khác. Tôi đã thực hiện nhiều thay đổi cho nó và không muốn mồ côi lịch sử SVN, vì vậy trong chi nhánh của tôi, tôi đã chuyển tệp từ thư mục của hội đồng khác. Điều này không được SVN theo dõi, vì vậy có vẻ như tệp bị xóa và sau đó được thêm lại. Điều này kết thúc gây ra một cuộc xung đột cây.

Tôi đã giải quyết vấn đề bằng cách di chuyển tệp trở lại, cam kết và sau đó hợp nhất chi nhánh của tôi. Sau đó tôi chuyển tập tin trở lại. :) Điều đó dường như để làm các mẹo.

Tôi đã có một vấn đề tương tự. Điều duy nhất thực sự hiệu quả với tôi là xóa các thư mục con bị xung đột với:

svn delete --force ./SUB_DIR_NAME

Sau đó sao chép lại chúng từ một thư mục gốc khác trong bản sao làm việc có chúng với:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Sau đó làm

svn cleanup

và

svn add *

Bạn có thể nhận được cảnh báo với người cuối cùng, nhưng chỉ cần bỏ qua chúng và cuối cùng

svn ci .

Tôi đã có vấn đề tương tự, và giải quyết nó bằng cách thực hiện lại việc hợp nhất bằng các hướng dẫn này . Về cơ bản, nó sử dụng "hợp nhất 2 URL" của SVN để cập nhật trunktrạng thái hiện tại của chi nhánh của bạn, mà không bận tâm quá nhiều về lịch sử và xung đột cây. Cứu tôi khỏi việc sửa thủ công 114 xung đột cây.

Tôi không chắc liệu nó có bảo tồn lịch sử như người ta muốn hay không, nhưng nó đáng giá trong trường hợp của tôi.

Một kịch bản mà đôi khi tôi gặp phải:

Giả sử bạn có một thân cây, từ đó bạn đã tạo một nhánh phát hành. Sau một số thay đổi trên trung kế (cụ thể là tạo thư mục "some-dir"), bạn tạo một nhánh tính năng / sửa lỗi mà sau đó bạn muốn hợp nhất vào nhánh phát hành (vì các thay đổi đủ nhỏ và tính năng / sửa lỗi rất quan trọng để phát hành) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Nếu sau đó bạn cố gắng hợp nhất nhánh tính năng / sửa lỗi trực tiếp vào nhánh phát hành, bạn sẽ gặp xung đột cây (mặc dù thư mục thậm chí không tồn tại trong nhánh tính năng / sửa lỗi):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Vì vậy, bạn cần hợp nhất một cách rõ ràng các cam kết đã được thực hiện trên thân cây trước khi tạo nhánh tính năng / sửa lỗi tạo thư mục "some-dir" trước khi hợp nhất nhánh tính năng / sửa lỗi.

Tôi thường quên rằng điều đó là không cần thiết trong git.