Trong Subversion (và CVS), kho lưu trữ là đầu tiên và quan trọng nhất. Trong git và thương mại không thực sự có khái niệm kho lưu trữ theo cách giống nhau; ở đây những thay đổi là chủ đề trung tâm.
+1
Rắc rối trong CVS / SVN xuất phát từ thực tế là các hệ thống này không
nhớ thời gian thay đổi của cha mẹ. Trong Git và Mercurial, không chỉ một cam kết có thể có nhiều con mà còn có thể có nhiều cha mẹ!
Điều đó có thể dễ dàng quan sát bằng cách sử dụng một trong các công cụ đồ họa, gitkhoặc hg
view. Trong ví dụ sau, nhánh # 2 đã được chia nhỏ từ # 1 tại cam kết A và kể từ đó đã được hợp nhất một lần (tại M, được hợp nhất với cam kết B):
o---A---o---B---o---C (branch #1)
\ \
o---o---M---X---? (branch #2)
Lưu ý rằng A và B có hai người con, trong khi M có hai cha mẹ . Các mối quan hệ này được ghi lại trong kho lưu trữ. Giả sử người bảo trì nhánh số 2 bây giờ muốn hợp nhất các thay đổi mới nhất từ nhánh số 1, họ có thể đưa ra lệnh như:
$ git merge branch-1
và công cụ sẽ tự động biết rằng cơ sở là B - vì nó đã được ghi lại trong cam kết M, tổ tiên của mẹo # 2 - và nó phải kết hợp bất cứ điều gì đã xảy ra giữa B và C. CVS không ghi lại thông tin này. , SVN trước phiên bản 1.5 cũng vậy. Trong các hệ thống này, biểu đồ sẽ giống như sau:
o---A---o---B---o---C (branch #1)
\
o---o---M---X---? (branch #2)
trong đó M chỉ là một cam kết khổng lồ "bị bóp nghẹt" về mọi thứ đã xảy ra giữa A và B, được áp dụng trên M. Lưu ý rằng sau khi hành động được thực hiện, không có dấu vết nào để lại (ngoại trừ có thể có trong các nhận xét có thể đọc được của con người) về nơi M đã bắt nguồn từ đâu, cũng không có bao nhiêu cam kết bị sụp đổ cùng nhau - làm cho lịch sử trở nên bất khả xâm phạm hơn nhiều.
Tệ hơn nữa, việc thực hiện hợp nhất thứ hai trở thành một cơn ác mộng: người ta phải tìm ra cơ sở hợp nhất là gì tại thời điểm hợp nhất đầu tiên (và người ta phải biết
rằng đã có một lần hợp nhất ngay từ đầu!), Sau đó trình bày điều đó thông tin đến công cụ để nó không cố gắng phát lại A..B trên đầu M. Tất cả điều này đủ khó khi làm việc với sự cộng tác chặt chẽ, nhưng đơn giản là không thể trong môi trường phân tán.
Một vấn đề (liên quan) là không có cách nào để trả lời câu hỏi: "X có chứa B không?" trong đó B là bản sửa lỗi quan trọng tiềm ẩn. Vì vậy, tại sao không chỉ ghi lại thông tin đó trong cam kết, vì nó đã được biết vào thời điểm hợp nhất!
P.-S. - Tôi không có kinh nghiệm về khả năng ghi hợp nhất SVN 1.5+, nhưng quy trình làm việc dường như phức tạp hơn nhiều so với các hệ thống phân tán. Nếu điều đó thực sự là như vậy, có thể là vì - như đã đề cập trong nhận xét ở trên - trọng tâm được đặt vào tổ chức kho lưu trữ hơn là bản thân những thay đổi.