Kiểm soát sửa đổi nào có công cụ hợp nhất tốt nhất? [đóng cửa]

Khi hợp nhất, mỗi phiên bản điều khiển có động cơ để thực hiện. Xung đột là không thể tránh khỏi nhưng câu hỏi là - kiểm soát sửa đổi nào có AI tốt nhất để tránh xung đột.

Có thể đo lường điều đó?

Cụ thể hơn, chúng tôi đang nghĩ sẽ chuyển sang GIT vì nó có sự cường điệu và tin đồn xử lý xung đột tốt hơn ...

Mọi bình luận đều được đánh giá cao ...

Tôi không nghĩ rằng đây là câu hỏi đúng.

Vấn đề là có rất nhiều trường hợp góc và thuật toán "thông minh" để hợp nhất có thể khiến họ nghĩ rằng họ đã thực hiện hợp nhất một cách chính xác khi thực tế họ đã làm mất hoàn toàn mã của bạn. Nếu bạn may mắn, một sự hợp nhất tồi tệ như vậy gây ra lỗi thời gian biên dịch. Nếu bạn không may mắn, nó có thể đưa ra một lỗi tinh vi cần nhiều thời gian để theo dõi.

Git sử dụng thuật toán hợp nhất khá đơn giản và giơ tay và yêu cầu trợ giúp nếu nó không thể thực hiện hợp nhất. Theo tôi, đây chính xác là những gì bạn muốn hệ thống kiểm soát phiên bản của bạn làm. Số tiền đau buồn mà bạn đang bỏ qua là rất xứng đáng với thời gian bạn phải tự khắc phục xung đột. .

Người ta đã nói rằng thuật toán tốt nhất là đại số vá của Darcs . Codeville cũng có một thuật toán thú vị trong phát triển.
Tuy nhiên, vì tất cả các lý do thực tế, bất kỳ công cụ nào sử dụng hợp nhất ba chiều sẽ làm. Điều này bao gồm git (với các biến thể), mercurial, bazaar và rất nhiều công cụ bên ngoài (ngoại lệ đáng chú ý: opendiff và kính vạn hoa trên Mac), vì vậy với khả năng tốt là bạn đã sử dụng các tùy chọn tốt nhất; như @Peter lưu ý, có những trường hợp không có thuật toán nào có thể giúp bạn.

Tôi sử dụng git và mercurial nhưng câu hỏi của bạn nhớ cho tôi lý thuyết vá của darcs. Bạn sẽ có bài tập về nhà cho cuối tuần này.

• http://en.wikipedia.org/wiki/Darcs
• http://byorgey.wordpress.com/2008/02/04/gulk-haskell-and-patch-theory/
• http://byorgey.wordpress.com/2008/02/07/patch-theory- Dùts-part-i /
• http://byorgey.wordpress.com/2008/02/13/patch-theory-part-ii-some-basics/

PD: Đừng hỏi tôi về lý thuyết vá, rất phức tạp đối với tôi :)

Nó được gọi là Kiểm soát sửa đổi con người. (Động cơ hợp nhất của con người)

Chúng tôi sử dụng Seapine Surround và phần lớn nó thực hiện tốt việc hợp nhất, nhưng cách duy nhất để khắc phục xung đột hợp nhất mà kiểm soát nguồn không thể làm là thông qua sự can thiệp của con người.

Vì vậy, lời khuyên của tôi là:

Cố gắng hợp nhất nhanh chóng. Một cơn ác mộng là có một chi nhánh không tham gia vào tuyến chính trong gần 2 năm. Khi nó được sáp nhập, nhiều xung đột cần phải được giải quyết. Một nhà phát triển đã có được biệt danh "hợp nhất tổng thể" sau khi dành rất nhiều thời gian để khắc phục các sự cố hợp nhất.

Hãy cẩn thận với mã được tạo tự động từ trình hướng dẫn, vv Đôi khi điều này có thể là một nỗi đau thực sự để hợp nhất, một cách bí mật nếu hai nhánh tự động thay đổi trên cùng một tệp.

Cố gắng kiểm soát sự phát triển. Nếu nhà phát triển A tách rời các tệp mã X và Y, thì nhà phát triển B sẽ làm việc trên X và Y ở một nhánh khác không có ý nghĩa gì. Một phần của quản lý hợp nhất là thử và kiểm soát những gì đang được sửa đổi để tránh khả năng xảy ra xung đột hợp nhất.

Điều này không có nghĩa là 2 nhà phát triển không thể làm việc trên cùng một tệp trong 2 nhánh khác nhau. Nếu 1 nhà phát triển thêm phương thức A và một phương pháp bổ sung B khác, thì việc hợp nhất sẽ diễn ra không đau đớn.

Cuối cùng, sẽ luôn có một số xung đột cần sự can thiệp của con người. Bằng cách giữ chúng ở mức tối thiểu, bạn sẽ có kết quả hợp nhất tốt nhất.

Công cụ hợp nhất hoàn hảo sẽ hiểu ngữ nghĩa của tệp được hợp nhất: vì vậy nó phân tích cú pháp và hiểu mã nguồn. Tôi vẫn chưa thấy điều khiển phiên bản / công cụ hợp nhất như vậy ...

Hầu hết các công cụ hợp nhất hợp nhất các tập tin dưới dạng văn bản. Vì vậy, tôi sẽ không bao giờ dựa vào chúng một cách mù quáng, luôn luôn nên xem xét các thay đổi trước khi cam kết với chi nhánh của bạn.

Chúng tôi đang sử dụng Perforce, không hợp nhất tự động. Bất cứ khi nào tệp nguồn thay đổi so với cơ sở chung, nó sẽ cho biết tệp đích cần giải quyết ngay cả khi không có xung đột. Vì vậy, tôi mở công cụ hợp nhất chỉ để nhanh chóng nghĩ ra những người đi săn để kiểm tra xem họ có phù hợp không (và có được một bức tranh sơ bộ về những gì các đồng nghiệp khác đang làm), thường thì họ sẽ phù hợp và chấp nhận kết quả.

Tôi cũng đã đăng ký thông báo thay đổi của dòng chính để tôi hợp nhất các thay đổi với chi nhánh của mình càng sớm càng tốt để tôi có thể tránh các vấn đề sau này.

Ơ ...

Khi sử dụng mercurial (và cả git nữa, tôi khá chắc chắn) bạn chọn công cụ hợp nhất của mình, theo mặc định đó là kdiff3 nhưng bạn có thể sử dụng bất cứ thứ gì bạn thích (ngoài so sánh, p4merge, v.v.).

AFAIK công cụ hợp nhất và VCS thường hoàn toàn tách biệt , giống như trình biên dịch và trình soạn thảo văn bản của bạn. Lấy ví dụ XML và mã, bạn sẽ muốn những thứ khác nhau hợp nhất những thứ đó, chúng không hoạt động theo cùng một cách và do đó không thể được hợp nhất theo cùng một cách.

Nếu bạn đang chuyển đổi kiểm soát phiên bản vì bạn cần một công cụ hợp nhất tốt hơn, bạn đang làm điều đó vì những lý do sai, bạn chỉ nên chuyển đổi kiểm soát phiên bản khi công cụ bạn đang sử dụng hiện tại không phù hợp với quy trình của bạn (hoặc một công cụ khác sẽ cho phép bạn sử dụng một quy trình tốt hơn).

Xung đột là không thể tránh khỏi

Làm thế nào tốt một VCS xử lý xung đột trong một tập tin trong tâm trí của tôi một chút đánh giá cao. Đối với một điều, cách tốt nhất để giải quyết các xung đột như vậy là không có chúng ở nơi đầu tiên. Bao thanh toán phần mềm của bạn tốt và tiết lộ các bài tập với suy nghĩ trước sẽ giúp giảm đáng kể xung đột trong một cụm tệp (hãy để một mình trong một tệp). Thực hiện một công việc tồi tệ như ném vào quá nhiều lớp thần hoặc một tệp cấu hình chung mà mọi người phải sử dụng và mọi người đều muốn xử lý và bạn đang yêu cầu xung đột ở cấp độ tệp.

Mặt khác, tất cả đều sử dụng thuật toán (tệ hại) tương tự. Một ví dụ: Một bản phát hành alpha của dự án của chúng tôi đã bị rò rỉ bộ nhớ nhỏ. Đó là nhiều hơn một giọt nước chứ không phải là một rò rỉ, và rò rỉ dừng lại ở cuối thời gian khởi tạo. Đáng sửa chữa, không xứng đáng với một bản vá. Một trong những khách hàng của chúng tôi đã "khắc phục" vấn đề, đặt miễn phí ở sai vị trí. Vấn đề đã được khắc phục trong phiên bản tiếp theo. Khách hàng này đã hợp nhất bản phát hành mới thay vì thực hiện thay thế hoàn toàn (WTF?). Không có xung đột trong hợp nhất ba chiều; các cuộc gọi miễn phí được cách ly tốt với nhau. Vì vậy, bây giờ phần mềm đang giảm lõi do miễn phí gấp đôi.

Điều đang bị bỏ lỡ trong cuộc thảo luận là mức độ khó / tốn thời gian / dễ bị lỗi khi hợp nhất công việc của bạn trở lại dòng chính của phần mềm.

Trong svn, bạn

• Cam kết thay đổi chi nhánh của bạn.
• Hợp nhất thân cây vào chi nhánh của bạn.
• Nếu bạn có một dự án lớn, bạn có thể muốn nghĩ đến việc nghỉ giải lao hoặc đi ăn trưa.
• Xin cầu nguyện rằng bạn sẽ không thấy bất kỳ xung đột cây nào khi bạn quay lại.
• Cam kết kết quả hợp nhất vào chi nhánh của bạn.
• Hợp nhất chi nhánh của bạn vào thân cây.
• Nghỉ giải lao khác.
• Một lần nữa cầu nguyện rằng bạn sẽ không thấy bất kỳ xung đột cây nào khi bạn quay lại.
• Cam kết thay đổi của bạn trở lại vào thân cây.
• Đóng cửa của bạn để tránh xung đột với đồng nghiệp, những người đang cố gắng làm điều tương tự.

Đó là rất nhiều bước phi nguyên tử, quá nhiều nơi mà lỗi có thể len ​​vào (xung đột cây chỉ là khó chịu), và nó mất quá nhiều thời gian. Tôi đã thấy nhiều dự án đã từ bỏ việc sử dụng các chi nhánh bị lật đổ phần lớn nhờ vào quá trình hợp nhất rất tốn thời gian và dễ bị lỗi. Tôi thậm chí đã thấy nhiều dự án chuyển từ lật đổ hoàn toàn vì điều này.

Có một bộ thử nghiệm nhỏ gọi là hợp nhất - cái này so sánh hệ thống kiểm soát sửa đổi với các kịch bản hợp nhất trong thế giới thực. Đối với mỗi kịch bản, đảm bảo rằng một VCS có thể thực hiện đúng như sau:

• hợp nhất chi nhánh mà không có xung đột
• sản xuất mã biên dịch
• sản xuất mã hoạt động chính xác

Dựa trên số lượng thử nghiệm vượt qua khi hợp nhất-này, có vẻ như có hai tầng hiệu suất:

1. Darcs, Git
2. Chợ, Mercurial

Tùy thuộc vào ngôn ngữ lập trình nào bạn đang cố gắng hợp nhất, kết quả kiểm tra chính xác có thể có vấn đề. Xem trang web của dự án để biết bảng so sánh chi tiết.

Tôi đã sử dụng IBM / Rational ClearCase và việc hợp nhất nhiều chi nhánh của nó thật tuyệt vời. Chạy vòng quanh lật đổ. (Không có kinh nghiệm về Git hoặc đồng bóng.)