SVN có gì khó khăn khi sáp nhập?

Bản sao có thể có:
Tôi là một người đam mê Subversion, tại sao tôi nên xem xét hoặc không xem xét Mercurial hoặc Git hoặc bất kỳ DVCS nào khác?

Thỉnh thoảng, bạn nghe ai đó nói rằng kiểm soát phiên bản phân tán (Git, HG) vốn đã tốt hơn kiểm soát phiên bản tập trung (như SVN) vì việc hợp nhất là khó khăn và đau đớn trong SVN. Vấn đề là, tôi chưa bao giờ gặp rắc rối với việc sáp nhập vào SVN và vì bạn chỉ nghe thấy tuyên bố đó được đưa ra bởi những người ủng hộ DVCS chứ không phải bởi những người dùng SVN thực tế, nó có xu hướng nhắc nhở tôi về những quảng cáo đáng ghét trên TV nơi họ cố gắng bán cho bạn thứ bạn không cần bằng cách nhờ các diễn viên vụng về giả vờ rằng thứ bạn đã có và hoạt động tốt là cực kỳ khó sử dụng.

Và trường hợp sử dụng luôn được đưa ra là sáp nhập lại một chi nhánh, một lần nữa khiến tôi nhớ lại những quảng cáo sản phẩm rơm đó; nếu bạn biết bạn đang làm gì, bạn không nên (và không bao giờ phải) hợp nhất lại một chi nhánh ở nơi đầu tiên. (Tất nhiên là khó thực hiện khi bạn đang làm điều gì đó sai lầm cơ bản và ngớ ngẩn!)

Vì vậy, giảm giá cho trường hợp sử dụng rơm vô lý, việc sáp nhập SVN có gì khó khăn hơn so với sáp nhập trong hệ thống DVCS?

Đó là vì svn thiếu cấu trúc dữ liệu phù hợp để xác định chính xác tổ tiên chung mới nhất của hai nhánh. Đó không phải là vấn đề lớn đối với một chi nhánh chỉ được hợp nhất một lần, nhưng có thể gây ra nhiều xung đột hợp nhất sai lầm trong tình huống một số chi nhánh được hợp nhất nhiều lần.

Tôi không theo dõi svn rất chặt chẽ, nhưng sự hiểu biết của tôi là những vấn đề kỹ thuật cụ thể đó đã được khắc phục trong các phiên bản gần đây. Tuy nhiên, nó không được sửa sớm đủ để xua tan huyền thoại và những người đã thử DVCS cho các vụ sáp nhập đã mắc kẹt với nó vì những lý do khác.

nếu bạn biết bạn đang làm gì, bạn không nên (và không bao giờ phải) hợp nhất lại một chi nhánh ở nơi đầu tiên. (Tất nhiên là khó thực hiện khi bạn đang làm điều gì đó sai lầm cơ bản và ngớ ngẩn!)

Và đó là nguồn gốc của sự nhầm lẫn của bạn và toàn bộ vấn đề nói chung.

Bạn nói rằng việc sáp nhập các chi nhánh là "sai về cơ bản và ngớ ngẩn". Chà, đó chính xác là vấn đề: bạn đang nghĩ về các nhánh là những thứ không nên hợp nhất. Tại sao? Bởi vì bạn là người dùng SVN, người biết rằng việc hợp nhất các chi nhánh là khó khăn . Do đó, bạn không bao giờ làm điều đó, và bạn khuyến khích người khác không làm điều đó. Bạn đã được đào tạo để tránh sáp nhập; bạn đã phát triển các kỹ thuật mà bạn sử dụng để tránh hợp nhất.

Tôi là người dùng Mercurial. Ngay cả các dự án của riêng tôi, nơi tôi đang phát triển chỉ, tôi nhập các chi nhánh tất cả các thời gian . Tôi có một nhánh phát hành, mà tôi đặt một sửa chữa vào. Chà, tôi hợp nhất nó trở lại vào dòng chính để sửa lỗi ở đó.

Nếu tôi đang sử dụng SVN, tôi sẽ áp dụng một cấu trúc hoàn toàn khác của cơ sở mã. Tại sao? Bởi vì SVN làm cho việc hợp nhất trở nên khó khăn, và do đó bạn phát triển thành ngữ và kỹ thuật để tránh thực hiện việc hợp nhất phức tạp.

DVCS làm cho việc hợp nhất phức tạp trở nên dễ dàng vì chúng là trạng thái mặc định . Mọi thứ đều là một nhánh, nhiều hay ít, trong một DVCS. Vì vậy, toàn bộ cấu trúc của chúng được xây dựng từ đầu để làm cho việc hợp nhất dễ dàng hơn. Điều này cho phép bạn phát triển một quy trình công việc sử dụng hợp nhất hàng ngày, thay vì quy trình công việc SVN nơi bạn không bao giờ sử dụng hợp nhất.

Một thực tế đơn giản là: bạn nên tiếp cận DVCS theo một cách khác với SVN. Bạn nên sử dụng các thành ngữ thích hợp cho các loại hệ thống kiểm soát phiên bản rất khác nhau này. Trong SVN, bạn chấp nhận các thành ngữ không liên quan đến việc hợp nhất vì việc hợp nhất là khó khăn. Trong DVCS, bạn chấp nhận các thành ngữ thường sử dụng hợp nhất vì chúng không phải là vấn đề lớn.

Đúng công cụ cho đúng công việc.

Có điều là, các quy trình làm việc hợp nhất-tập trung là một rất nhiều đẹp hơn và dễ dàng hơn để sử dụng hơn so với quy trình làm việc SVN-phong cách mà bạn không hợp nhất mọi thứ. Dễ thấy hơn khi một cái gì đó từ nhánh phát hành được đưa vào nhánh dev. Dễ dàng hơn để thấy sự tương tác khác nhau giữa các chi nhánh. Thật dễ dàng để tạo các nhánh thử nghiệm cho mọi thứ, sau đó cắt bỏ chúng nếu thử nghiệm không hoạt động. Và như vậy.

Thực sự, Joel giải thích điều này tốt hơn nhiều so với tôi có thể . Bạn nên có một đọc tốt về điều đó.

Không có gì quá khó khăn về việc sáp nhập SVN ... nữa ... nếu bạn làm theo đúng triết lý

Những gì tôi thấy trong hầu hết các câu trả lời khác dường như đến từ những người chưa sử dụng SVN trong một thời gian. Như ai đó đã đề cập chính xác: "nó không được sửa sớm đủ để xua tan huyền thoại".

Từ kinh nghiệm hiện tại của tôi về việc sử dụng SVN 1.6 đến 1.8 cho một dự án cũ mà tôi đã kế thừa gần đây, SVN đã đi một chặng đường dài để biến việc sáp nhập trở nên dễ dàng hơn nhiều. Mặc dù vậy, nó không phải là hoàn hảo, và tôi nghĩ rằng nó không dễ dàng khiến người dùng đi chệch khỏi mục đích sử dụng.

Mặc dù tôi biết khá rõ về SVN và cũng đã từng thử Mercurial cho các dự án cá nhân, nhưng tôi chưa bao giờ thực hiện nhiều chi nhánh ở SVN trước dự án này. Có khá nhiều thử nghiệm và sai sót và tôi đã gặp rất nhiều xung đột hợp nhất bất ngờ khi tôi bắt đầu.

Cuối cùng, mặc dù, tôi nhận ra rằng mỗi khi tôi có một (hoặc một số vấn đề khác), đó là vì tôi đã không thực hiện đúng cách (hay còn gọi là "cách SVN" - có thể nói là cách kiểm soát phiên bản phù hợp). Tôi tin rằng đây là nơi khó khăn: bạn không thể làm bất cứ điều gì bạn muốn theo cách không có tổ chức và mong muốn SVN hoạt động hoàn hảo, đặc biệt là với việc sáp nhập. Sáp nhập đòi hỏi kỷ luật nghiêm ngặt từ (các) người dùng trước khi họ thể hiện sức mạnh thực sự của mình.

Dưới đây là những điều tôi nhận thấy là các khuyến nghị mạnh mẽ, nếu không phải là yêu cầu, cho việc sử dụng hợp nhất sạch sẽ:

• Sử dụng một phiên bản gần đây của SVN (theo ý kiến ​​của tôi trở lên). Ngày càng có nhiều tự động hóa và kiểm tra được thực hiện cho bạn.
• Sử dụng cấu trúc "thân, nhánh, thẻ" mặc định và áp dụng triết lý của nó (không cam kết với thẻ). SVN sẽ không kiểm tra bất cứ điều gì cho bạn. Nếu bạn sử dụng thẻ làm chi nhánh (đó là trạng thái tôi thấy kho lưu trữ dự án đó), nó vẫn có thể hoạt động, nhưng bạn cần nhất quán.
• Biết các nhánh là gì và khi nào tạo ra chúng. Tương tự với các thẻ.
• Giữ các nhánh bên cập nhật với nhánh nguồn của chúng (thường là thân cây, nhưng bạn có thể phân nhánh từ bất kỳ nhánh nào về mặt kỹ thuật). Đây là điều bắt buộc NẾU bạn muốn SVN thực hiện tự động sáp nhập. SVN 1.8 thực sự ngăn bạn tự động hợp nhất nếu mọi thứ không cập nhật và nếu bạn có các sửa đổi đang chờ xử lý trong bản sao làm việc của mình (hành vi này dường như đã biến mất một lần nữa trong 1.8.5).
• Làm "đúng" cam kết. Chúng chỉ nên chứa các sửa đổi trên một khái niệm rất cụ thể. Càng nhiều càng tốt, chúng nên chứa một lượng nhỏ thay đổi. Ví dụ, bạn không muốn có một cam kết chứa các sửa đổi về hai lỗi độc lập. Nếu bạn đã khắc phục cả hai và họ đang ở trong cùng một tập tin, bạn nên lưu trữ đi những thay đổi của một lỗi để bạn có thể cam kết chỉ những thay đổi của người kia đầu tiên, sau đó cam kết tập thứ hai của sự thay đổi. Lưu ý rằng TortoiseSVN cho phép điều này dễ dàng thông qua "Khôi phục sau khi cam kết".
  • Làm như vậy có thể hoàn nguyên một tập hợp thay đổi độc lập cụ thể VÀ làm cho chỉ có thể hợp nhất một tập hợp như vậy vào một nhánh khác. Có, SVN cho phép bạn hợp nhất các phiên bản anh đào đã chọn.
• Nếu bạn từng sử dụng các nhánh con (phân nhánh khỏi thân cây, sau đó phân nhánh khỏi nhánh mới đó), hãy tôn trọng hệ thống phân cấp. Nếu bạn cập nhật nhánh con với thân cây hoặc ngược lại, bạn sẽ cảm thấy đau đớn. Sáp nhập nên được xếp tầng hoặc lên thứ bậc.
  • Sau một vài tháng thử nghiệm, tôi có thể khẳng định rằng đây có thể là phần quan trọng nhất. Đã thử tạo hai nhánh con từ cùng một thân cây và sau đó hợp nhất các bit giữa các nhánh con hoặc đôi khi giữa các nhánh con từ hai phía. Điều này có thể tăng SVN (hoặc người dùng). Nó có thể hoạt động tốt nếu bạn hợp nhất các phiên bản cụ thể. Tự động hợp nhất có thể có vấn đề với nó.
  • Tôi đã gặp sự cố cụ thể khi đồng bộ hóa nhánh con A với thân cây, và sau đó cố gắng hợp nhất một thứ gì đó từ nhánh con A thành nhánh con B. SVN dường như nghĩ rằng việc sửa đổi "đồng bộ hóa từ thân cây" nên được hợp nhất thành nhánh con B và điều này dẫn đến một loạt các xung đột.
• Càng nhiều càng tốt, hợp nhất từ ​​gốc của chi nhánh. Nếu không, SVN sẽ chỉ theo dõi các thao tác trộn làm cho các thư mục con và khi bạn làm thử để tự động merge từ gốc, bạn có thể nhận được cảnh báo về việc thiếu các phiên bản Đã hủy. Nó có thể sửa được bằng cách đơn giản là hợp nhất những thứ này từ gốc, nhưng tốt nhất là tránh nhầm lẫn.
• Hãy cẩn thận với chi nhánh mà bạn cam kết. Nếu bạn sử dụng Chuyển đổi để có điểm sao chép hoạt động của bạn đến các chi nhánh khác nhau theo thời gian, hãy chắc chắn nơi bạn cam kết.
  • Điều này đặc biệt tệ nếu bạn thực sự không muốn thay đổi trong chi nhánh đó . Tôi vẫn chưa rõ về điều đó, nhưng tùy thuộc vào cách bạn loại bỏ nó / chuyển nó vào nhánh bên phải (hoàn nguyên, hợp nhất), bạn có thể nhận được một cái gì đó lộn xộn. Có thể sửa được, nhưng bạn sẽ phải hợp nhất sửa đổi bằng cách sửa đổi để tránh hoặc giải quyết ngay lập tức các xung đột tiềm ẩn hoặc bạn sẽ phải khắc phục một xung đột phức tạp hơn có thể sau khi tự động hợp nhất.
• Đừng để các nhánh không bị ảnh hưởng quá lâu. Trên thực tế, đó không phải là vấn đề thời gian mà là có bao nhiêu sửa đổi được cam kết cho chi nhánh và thân cây và bao nhiêu thay đổi trong những điều này. Sáp nhập giữa hai nhánh, hợp nhất 3 chiều, luôn được so sánh với sửa đổi chung gần đây nhất giữa các nhánh. Càng nhiều thay đổi ở giữa, càng nhiều thay đổi, việc hợp nhất tự động sẽ thất bại. Tất nhiên, điều này tệ hơn nhiều nếu bạn thay đổi cấu trúc mã của mình trong thời gian đó (di chuyển hoặc đổi tên tệp).

Nếu bạn không làm theo những điều trên, bạn hoàn toàn có khả năng bị xung đột. Họ luôn luôn có thể giải quyết được, nhưng không vui lắm khi dành thời gian cho nó.

Ồ, một điều nữa về việc hợp nhất ở đâu, từ tất cả những gì tôi đã đọc và thử, SVN thực sự rất tệ: đã xóa / di chuyển / đổi tên tập tin / thư mục. Rõ ràng , SVN vẫn không thể xử lý một tệp bị đổi tên, xóa hoặc di chuyển trong một nhánh và phiên bản gốc của nó được sửa đổi trong một nhánh khác ... và sau đó hợp nhất các tệp này lại với nhau. Nó sẽ không biết tập tin đã đi theo một cách nào và sẽ "quên" những thay đổi theo cách khác. Một thay đổi rõ ràng là không thể giải quyết được (bạn có thể xóa hoặc thay đổi tệp, không thể thực hiện cả hai), nhưng áp dụng thay đổi cho các tệp được di chuyển / đổi tên sẽ hoạt động và nó không hoạt động. Hy vọng điều này sẽ được khắc phục sớm.

Vì vậy, tất cả trong tất cả, SVN hợp nhất dễ dàng? Tôi đoán là không. Chắc chắn không phải là một cách vô tư. Có tệ không Tôi không nghĩ vậy. Nó chỉ quay trở lại vào mặt bạn khi bạn sử dụng sai cách và không nghĩ đủ về những gì bạn đang làm.

Dựa trên điều này, tôi có thể thấy lý do tại sao mọi người có thể thích Mercurial (ví dụ) vì nó nhẹ nhàng hơn về những điều này từ kinh nghiệm của tôi và có mọi thứ tự động từ việc di chuyển (ít nhất là từ các phiên bản đầu tiên tôi bắt đầu). SVN đã bắt kịp khá nhiều, tuy nhiên, vì vậy nó không xứng đáng với quá nhiều bash nữa.

Các mô hình dữ liệu nội bộ về cơ bản là khác nhau.

Về cơ bản, ở SVN, khi bạn nhìn vào lịch sử của một chi nhánh, bạn chỉ thấy những gì đã xảy ra trong chi nhánh đó. Vì vậy, khi bạn hợp nhất từ ​​nhánh này Bsang nhánh khác A, lịch sử của nhánh Asẽ chứa một cam kết lớn chứa tất cả các thay đổi được thực hiện rõ ràng Bkể từ khi nó được phân nhánh.

Trong các phiên bản đầu tiên của SVN, nếu bạn phải hợp nhất chi nhánh Bthành chi nhánh Amột lần nữa, bạn phải chỉ định thủ công phạm vi sửa đổi của chi nhánh Bmà bạn muốn hợp nhất để tránh hợp nhất hai lần sửa đổi. Nhà phát triển thông minh tất nhiên sẽ sử dụng một thông điệp cam kết như 'Đã hợp nhất trong B: 1234'.

SVN 1.5 "cố định" cái này. Nhưng nó không thay đổi cách áp dụng sáp nhập một cách cơ bản. Nó chỉ thêm một số siêu dữ liệu bổ sung vào chi nhánh A, cho SVN biết rằng phiên bản 1234 đã được hợp nhất, cho phép SVN tự động chọn phạm vi sửa đổi chính xác.

Nhưng giải pháp này về cơ bản là một giải pháp cho một mô hình dữ liệu về cơ bản không hỗ trợ theo dõi những gì đã được hợp nhất.

Hợp nhất hai nhánh là một ví dụ tương đối đơn giản. Nhưng hình ảnh kịch bản phức tạp hơn này

1. Tạo chi nhánh Atừ trunkvà thực hiện một số cam kết tại đây
2. Tạo chi nhánh Btừ Avà thực hiện một số cam kết ở đây
3. Thực hiện một vài cam kết trong trunkvàA
4. Hợp nhất Bthànhtrunk
5. Hợp nhất AthànhB
6. Hợp nhất Athànhtrunk
7. Hợp nhất Bvào trunk(điều này thực sự không nên làm gì cả)

Xử lý chính xác việc sử dụng mô hình siêu dữ liệu này trở nên cực kỳ phức tạp (Tôi không biết liệu SVN có thực sự xử lý chính xác kịch bản này hay không và tôi không cảm thấy có xu hướng kiểm tra nó).

Xử lý tình huống này trong git là cực kỳ đơn giản.

Trong git, mỗi khi bạn cam kết, đối tượng bên trong đại diện cho cam kết đó chứa tham chiếu đến phần đầu trước đó. Khi bạn hợp nhất trong một nhánh, cam kết chứa tham chiếu đến đầu trước của tất cả các nhánh được hợp nhất (bạn có thể hợp nhất nhiều nhánh tại một thời điểm trong git)

Do đó, khi bạn kiểm tra lịch sử của một cam kết trong git, bạn có thể thấy tất cả lịch sử, bạn có thể thấy khi nào nó được phân nhánh, khi nó được hợp nhất và bạn có thể thấy lịch sử của cả hai nhánh giữa phân nhánh và sáp nhập.

Do đó, khi sáp nhập trong một nhánh đã được sáp nhập một phần, việc xác định những gì đã được sáp nhập là vô cùng đơn giản và những gì chưa được hợp nhất.

Tôi không có kinh nghiệm với Mercurial, nhưng tôi nghi ngờ rằng hoạt động bên trong của nó tương tự như git.

Về cơ bản, đối với SVN, đó là một mục tiêu thiết kế để làm cho chi nhánh rẻ. Nhưng trong git, đó là một mục tiêu thiết kế để làm cho việc sáp nhập giá rẻ.

Cuối cùng, lần trước tôi đã sử dụng SVN, nó không thể xử lý các phép hợp nhất, trong đó một tệp được đổi tên trong một nhánh và được sửa đổi trong một nhánh khác.

Tôi đã thực hiện một chút hợp nhất SVN - bao gồm cả việc phát triển và phát hành các nhánh dài. Bởi và lớn tôi đã sống sót. Việc hợp nhất luôn luôn khó khăn, nhưng với DCVS, nhược điểm không tệ lắm - mọi thứ đều mang tính địa phương nên chỉ cần cập nhật lên bản sửa đổi tốt đã biết và tiếp tục. Trong khi đó với SVN rất nhiều đã xảy ra ở phía máy chủ nên việc khôi phục rất tệ - thường thì nó liên quan đến việc xóa sạch bản sao cục bộ sau đó kiểm tra một nhánh sạch mới để thử lại. Trường hợp của tôi không tệ - kết nối gigabit với hộp SVN giúp. Nhưng chúng tôi đã có một số nhà thầu gặp nhiều rắc rối với vấn đề này vì họ ở trên các kết nối chậm nên mọi thứ diễn ra mãi mãi, bao gồm cả việc sáp nhập.

Vâng, tôi cũng làm điều đó. Tôi hiện có 12 máy ảo cho các phiên bản (chi nhánh) khác nhau của dự án mà tôi đang làm việc. Khi tôi phải sửa một lỗi trong phiên bản cũ hơn, tôi sửa lỗi đó, sau đó hợp nhất cam kết đó vào các nhánh cho các phiên bản mới hơn. Nhưng đó là bây giờ hợp nhất lại toàn bộ một chi nhánh, đó là những gì tôi đang nói ở đây.

Đây là một trong những điều rất hay về git. Nó không được thừa hưởng về DVCS, nó chỉ là một cái gì đó git vượt trội. Bạn có thể hợp nhất các phiên bản cụ thể từ bất kỳ chi nhánh nào vào một chi nhánh khác. Về cơ bản, nó chỉ lấy diff và áp dụng nó cho nhánh khác, nhưng thực hiện theo dõi và tự động hơn nhiều.

Vì vậy, nếu bạn có nhánh 2.0 và nhánh 3.0 và phát hiện ra lỗi trong 2.0, thì bạn có thể sửa nó trong 2.0 và lấy tập hợp các phiên bản giải quyết nó và chỉ hợp nhất các sửa đổi đó vào nhánh 3.0. Tôi không tin SVN có bất kỳ cách nào để làm điều này ngoài việc lấy các khác biệt theo cách thủ công cho mỗi lần sửa đổi và áp dụng chúng

Tất nhiên, thuật toán tự động hợp nhất cũng có vẻ hoạt động mượt mà hơn và git được xây dựng từ nền tảng của mô hình "tạo một nhánh cho tất cả mọi thứ", vì vậy việc phân nhánh thực sự rất trơn tru và dễ dàng. Nó có vẻ tự nhiên để phân nhánh thường xuyên với các nhánh nhẹ như thế nào