Có sự khác biệt giữa sáp nhập trong svn so với git hoặc đồng bóng?

Theo hiểu biết của tôi, SVN là 'Dễ dàng phân nhánh. Khó hợp nhất '. Tại sao vậy? Có một sự khác biệt làm thế nào họ hợp nhất?

Vui lòng xem câu trả lời Stack Overflow của tôi cho một tình huống rất cụ thể trong đó Mercurial (và Git) hợp nhất mà không gặp vấn đề gì và khi Subversion trình bày cho bạn một cuộc xung đột không có thật. Tình huống này là một phép tái cấu trúc đơn giản được thực hiện trên một nhánh nơi bạn đổi tên một số tệp.

Liên quan đến câu trả lời của tdammers, sau đó có một số hiểu lầm ở đó:

• Subversion, Mercurial và Git đều theo dõi các ảnh chụp nhanh trên toàn kho lưu trữ của dự án. Gọi họ phiên bản , sửa đổi , hoặc changesets làm cho không có sự khác biệt. Chúng đều là ảnh chụp nhanh nguyên tử của một tập hợp các tệp.

• Kích thước của các cam kết của bạn không có sự khác biệt khi hợp nhất. Tất cả ba hệ thống hợp nhất với thuật toán hợp nhất ba chiều tiêu chuẩn và các đầu vào cho thuật toán đó là

  • phiên bản tổ tiên chung lớn nhất
  • phiên bản trên một nhánh
  • phiên bản trên nhánh khác

  Không quan trọng làm thế nào hai phiên bản chi nhánh được tạo ra. Bạn có thể đã sử dụng 1000 cam kết nhỏ kể từ phiên bản tổ tiên hoặc bạn có thể đã sử dụng 1 cam kết. Tất cả những gì quan trọng là phiên bản cuối cùng của các tập tin. (Vâng, điều này thật đáng ngạc nhiên! Vâng, rất nhiều hướng dẫn DVCS đã nhận sai lầm khủng khiếp này.)

Ông cũng nêu lên một số điểm tốt về sự khác biệt:

• Subversion có một số "voodoo" nơi bạn có thể hợp nhất từ /trunk, nói , /branches/foo. Mercurial và Git không sử dụng mô hình này - các nhánh thay vào đó được mô hình hóa trực tiếp trong lịch sử. Do đó, lịch sử trở thành một biểu đồ chu kỳ có hướng thay vì tuyến tính. Đây là một mô hình đơn giản hơn nhiều so với mô hình được sử dụng bởi Subversion và điều này cắt đi một số trường hợp góc.

• Bạn có thể dễ dàng trì hoãn hợp nhất hoặc thậm chí để người khác xử lý nó. Nếu hg mergecung cấp cho bạn rất nhiều xung đột, thì bạn có thể yêu cầu đồng nghiệp của bạn hg pulltừ bạn và sau đó anh ta có trạng thái chính xác như vậy. Vì vậy, anh ta có thể hg mergevà có thể anh ta tốt hơn trong việc giải quyết xung đột hơn bạn.

  Điều này rất khó với Subversion nơi bạn bắt buộc phải cập nhật trước khi bạn có thể cam kết. Bạn không thể bỏ qua các thay đổi trên máy chủ và tiếp tục cam kết trên nhánh ẩn danh của riêng bạn. Nói chung, Subversion buộc bạn phải chơi xung quanh với một bản sao làm việc bẩn khi bạn svn update. Đây là một loại rủi ro vì bạn đã không lưu trữ các thay đổi của mình ở bất cứ đâu an toàn. Git và Mercurial cho phép bạn cam kết trước, sau đó cập nhật và hợp nhất khi cần thiết.

Lý do thực sự khiến Git và Mercurial hợp nhất tốt hơn Subversion là vấn đề thực hiện. Có những xung đột đổi tên mà Subversion chỉ đơn giản là không thể xử lý thậm chí còn nghĩ rằng câu trả lời đúng là gì. Mercurial và Git xử lý những người dễ dàng. Nhưng không có lý do tại sao Subversion không thể xử lý tốt những điều đó - tập trung hóa chắc chắn không phải là lý do.

Vấn đề cốt lõi nằm ở cách các hệ thống này thể hiện cấu trúc thư mục được phiên bản.

Khái niệm cơ bản của Subversion mà toàn bộ hệ thống xoay quanh là phiên bản (hoặc, trong singo lingo, "revision"): ảnh chụp nhanh của một tệp tại một điểm nhất định. Miễn là lịch sử hoàn toàn tuyến tính, tất cả đều ổn, nhưng nếu bạn cần hợp nhất các thay đổi từ hai dòng phát triển độc lập, svn phải so sánh các phiên bản hiện tại của cả hai, và sau đó thực hiện so sánh ba chiều giữa phiên bản chia sẻ cuối cùng và hai phiên bản đầu. Các dòng xuất hiện thay đổi ở một trong những đầu, nhưng không phải là đầu khác, có thể dễ dàng được giải quyết; các đường lệch chính xác theo cùng một cách trong cả hai đầu thì khó hơn, nhưng thường có thể thực hiện được; những dòng đi chệch hướng theo những cách khác nhau là điều khiến svn nói "Tôi không thể hiểu điều này, con người, xin vui lòng giải quyết vấn đề này cho tôi."

Ngược lại, git và theo dõi lanh lợi changesets chứ không phải phiên bản. Toàn bộ kho lưu trữ là một cây thay đổi, mỗi bộ tùy thuộc vào cha mẹ, trong đó bộ thay đổi cha mẹ có thể có bất kỳ số lượng con nào và gốc cây đại diện cho một thư mục trống. Nói cách khác, git / hg nói "đầu tiên tôi không có gì, sau đó bản vá này được áp dụng, sau đó là bản vá đó, v.v.". Khi bạn cần hợp nhất hai dòng phát triển, git / hg không chỉ biết mỗi đầu hiện tại trông như thế nào và phiên bản chung cuối cùng trông như thế nào, nó còn biết quá trình chuyển đổi xảy ra như thế nào, cho phép hợp nhất thông minh hơn nhiều.

Một điều nữa làm cho việc hợp nhất dễ dàng hơn trong DVCS là hậu quả gián tiếp của việc tách biệt các khái niệm về cam kết và thúc đẩyvà cho phép tất cả các loại hợp nhất chéo giữa bất kỳ hai bản sao của cùng một kho lưu trữ bất cứ lúc nào. Với svn, mọi người có xu hướng cam kết các thay đổi lớn với các thay đổi thường không liên quan, bởi vì một cam kết cũng là một bản cập nhật trên kho lưu trữ trung tâm ảnh hưởng đến tất cả các thành viên khác trong nhóm; nếu bạn phạm phải một phiên bản bị hỏng, mọi người sẽ tức giận với bạn. Vì hầu hết các thiết lập liên quan đến máy chủ svn được nối mạng, nên việc cam kết cũng liên quan đến việc bơm dữ liệu qua mạng, điều đó có nghĩa là cam kết giới thiệu một độ trễ đáng kể cho quy trình làm việc (đặc biệt là khi bản sao làm việc của bạn đã lỗi thời và bạn phải kéo trước). Với git và mercurial, cam kết xảy ra cục bộ và vì cả hai đều rất hiệu quả trong việc xử lý các hệ thống tệp cục bộ, nên nó thường kết thúc ngay lập tức. Kết quả là, mọi người (một khi họ đã quen với nó) cam kết những thay đổi nhỏ dần, và sau đó khi nó hoạt động, đẩy một tá hoặc hơn cam kết trong một lần. Sau đó, khi thời gian hợp nhất xuất hiện, SCM có nhiều thông tin chi tiết hơn và có thể thực hiện công việc tốt hơn để giải quyết xung đột một cách an toàn và tự động.

Và sau đó là những chi tiết đẹp khiến mọi thứ trở nên dễ dàng hơn:

• Bạn có thể có nhiều đầu và vẫn cam kết trên một trong hai; Không giống như lật đổ, bạn không cần kết hợp kéo, cập nhật và hợp nhất trước khi cam kết lại - nhiều đầu chỉ giữ nguyên như vậy cho đến khi bạn chọn hợp nhất
• Thư mục không được đối xử đặc biệt; thay vào đó, đường dẫn chỉ được coi là một tên tệp lớn và tất cả các thư mục của bạn phải ở cùng một phiên bản mọi lúc. Điều này có nghĩa là bạn không thể thực hiện lật đổ voodoo nơi các thư mục con của dự án ở các phiên bản khác nhau, nhưng điều đó cũng có nghĩa là bản sao làm việc ít có khả năng trở thành một mớ hỗn độn bị hỏng không thể quản lý được và thú vị hơn, một động thái không được thể hiện dưới dạng xóa -và thêm (sẽ phá vỡ hoàn toàn trong svn nếu nó không dành cho siêu dữ liệu trang bị thêm), nhưng chỉ đơn giản là đổi tên; nếu bạn di chuyển một tập tin, toàn bộ lịch sử của nó được bảo tồn; hợp nhất thậm chí có thể áp dụng các thay đổi cho tệp đã di chuyển được thực hiện cho phiên bản không di chuyển của cùng một tệp sau khi di chuyển, trong một nhánh khác
• Hầu hết thời gian, bạn thực sự thậm chí không cần phải phân nhánh: thay vào đó, bạn chỉ cần sao chép toàn bộ kho lưu trữ. Nhân bản là rẻ, đặc biệt là nếu nó được thực hiện trên cùng một hệ thống tập tin và nếu bạn quyết định muốn thoát khỏi bản sao, bạn chỉ cần xóa thư mục mà nó sống và đó là. Bạn thậm chí không cần sử dụng hg hoặc git cho điều đó.
• Có một vài hạn chế (nếu có) về những gì bạn có thể hợp nhất. Bạn có thể có sáu bản sao của cùng một kho lưu trữ và hợp nhất (hoặc đúng hơn là đẩy hoặc kéo; một sự hợp nhất rõ ràng thường không bắt buộc) từ A đến B, sau đó C đến B, sau đó B đến D, sau đó C đến D, B trở lại đến A, D đến E, bất cứ lúc nào và bao nhiêu lần bạn muốn.
• Bạn có thể kiểm tra hợp nhất bằng cách nhân bản một trong các kho lưu trữ mà bạn muốn hợp nhất, sau đó kéo vào đó từ kho kia. Nếu nó làm những gì bạn muốn, bạn có thể đẩy lùi về mục tiêu thực sự, nếu không, bạn sẽ vứt bỏ bản sao và bắt đầu lại từ đầu.