Tất cả các hệ kiểm soát phiên bản đều phải giải quyết một vấn đề cơ bản: bằng cách nào hệ thống cho phép người dùng chia sẽ thông tin nhưng vẫn có thể ngăn không để họ giẫm chân lên nhau? Rất dễ xảy ra việc người sử dụng ghi đè lên những thay đổi của người khác trong kho lưu trữ một cách vô ý.

Xem xét kịch bản thể hiện ở Figure 1.2, “Vấn đề cần tránh”. Giả sử chúng ta có hai người đồng nghiệp, Harry và Sally. Mỗi người đều quyết định sẽ chỉnh sửa cùng một tập tin cùng thời điểm. Nếu Harry lưu những thay đổi của anh ấy vào kho lưu trữ trước, thì có nhiều khả năng là (một lát sau) Sally có thể ghi đè lên những thay đổi này với phiên bản tập tin mới hơn của cô ấy một cách vô tình. Mặc dù phiên bản của Harry sẽ không bị mất hẵn (bởi vì hệ thống ghi nhớ mỗi thay đổi), bất kỳ thay đổi nào mà Harry tạo ra sẽ không được hiện diện trong phiên bản tập tin mới hơn của Sally, bởi vì cô ấy không biết về những thay đổi của Harry để tiếp tục nối vào. Những thay đổi của Harry vẫn bị mất—hoặc ít nhất là không có mặt trong phiên bản mới nhất của tập tin—chắc chắn chỉ vì vô ý. Đó hiển nhiên là một tình huống mà chúng ta cần tránh!

Nhiều hệ thống kiểm soát phiên bản sử dụng mô hình khoá-sửa đổi-mở khoá để giải quyết vấn đề nhiều tác giả đụng độ liên tục những thay đổi của nhau. Trong mô hình này, kho lưu trữ chỉ cho phép thay đổi của một người duy nhất ở một thời điểm. Chính sách độc quyền này được thực thi bằng việc sử dụng khóa. Harry cần phải “khóa” một tập tin trước khi anh ấy có thể bắt đầu hiệu chỉnh nó. Nếu Harry đã khóa tập tin, Sally không thể khóa nó, và như vậy là không thể tạo ra bất kỳ thay đổi nào trên tập tin đó. Tất cả những điều cô ấy có thể làm là đợi Harry hoàn thành những thay đổi của anh ấy, lưu tập tin và mở khóa. Sau khi Harry mở khóa tập tin, Sally tới lượt mình có thể khóa tập tin. Tiếp theo cô ấy có thể lấy phiên bản mới nhất của tập tin và hiệu chỉnh nó. Figure 1.3, “Giải pháp khoá-sửa đổi-mở khoá”trình bày giải pháp đơn giản này.

Vấn đề của mô hình khoá-sửa đổi-mở khoá này là nó hơi hạn chế và thường hay trở thành một rào cản đối với người sử dụng:

Subversion, CVS và nhiều hệ kiểm soát phiên bản khác sử dụng mô hình sao chép-sửa đổi-hợp nhất như là phương án thay thế cho khóa. Trong mô hình này, mỗi ứng dụng khách của người sử dụng kết nối với kho lưu trữ dự án và tạo một bản sao làm việc riêng. Người sử dụng sau đó làm việc đồng thời và độc lập với nhau chỉnh sửa phiên bản sao chép riêng của họ. Sau cùng, những bản sao riêng lẻ được hợp nhất với nhau thành một bản mới, phiên bản cuối cùng. Hệ thống kiểm soát phiên bản thường hỗ trợ việc hợp nhất, nhưng sau cùng, người quản trị có trách nhiệm thực hiện việc hợp nhất một cách chính xác.

Đây là một ví dụ. Giả sử rằng Harry và Sally mỗi người tạo một bản sao làm việc của cùng một dự án, sao chép từ kho lưu trữ. Họ làm việc đồng thời và thay đổi trên cùng một tập tin A trong bản sao của họ. Sally lưu những thay đổi của cô ấy vào kho lưu trữ trước. Khi Harry cố gắng để lưu những thay đổi của anh ấy sau đó, kho lưu trữ thông báo với anh ấy rằng tập tin A của anh ấy quá hạn. Nói cách khác, tập tin A trong kho lưu trữ đã bị thay đổi theo cách nào đó kể từ lúc anh ấy sao lưu nó. Vì vậy Harry ra lệnh cho ứng dụng khách của anh ấy hợp nhất bất kỳ thay đổi mới nào từ trên kho lưu trữ vào trong bản sao làm việc của tập tin A của anh ấy. Nhiều khả năng là những thay đổi của Sally không bị chồng chéo với những thay đổi của riêng anh ấy; khi hai phần đã được tích hợp vào với nhau, anh ấy lưu bản sao làm việc của anh ấy vào trong kho lưu trữ. Figure 1.4, “Giải pháp sao chép-sửa đổi-hợp nhất” và Figure 1.5, “Giải pháp sao chép-sửa đổi-hợp nhất (tiếp theo)” biểu diễn quy trình này.

Nhưng sẽ như thế nào nếu thay đổi của Sally thật sự chồng chéo với thay đổi của Harry? Điều gì sau đó? Tình huống này gọi là xung đột, và thông thường thì nó không hẵn là một vấn đề. Khi Harry ra lệnh cho ứng dụng khách của anh ấy hợp nhất những thay đổi mới nhất trên kho vào trong bản sao làm việc của anh ấy, bản sao của tập tin A của anh ấy theo cách nào đó được đánh dấu như là đang ở trạng thái xung đột: anh ấy có thể thấy cả hai phần của những thay đổi đang gặp xung đột và chọn một trong hai một cách thủ công. Lưu ý rằng phần mềm không thể giải quyết xung đột một cách tự động; chỉ có con người mới có khả năng hiểu và thực hiện việc chọn lựa cần thiết một cách thông minh. Khi Harry đã giải quyết vấn đề những thay đổi chồng chéo một cách thủ công—có lẽ sau khi thảo luận với Sally—anh ấy có thể lưu tập tin được hợp nhất ngược lại vào trong kho lưu trữ.

Mô hình sao chép-sửa đổi-hợp nhất nghe có vẻ hơi hỗn loạn, nhưng trên thực tế, nó hoạt động rất mượt. Người sử dụng có thể làm việc song song, không bao giờ phải chờ đợi nhau. Khi họ làm việc trên cùng một tập tin, hoá ra rằng hầu hết những thay đổi đồng thời của họ không hoàn toàn không chồng lấn; xung đột là không thường xuyên. Và thời gian nó tiêu tốn để giải quyết xung đột thường là ít hơn nhiều so với thời gian bị mất bởi hệ thống khoá.

Cuối cùng, tất cả dẫn đến một yếu tố quan trọng: giao tiếp người sử dụng. Khi người dùng giao tiếp kém, cả hai loại xung đột cú pháp và xung đột ngữ nghĩa tăng. Không có hệ thống nào có thể bắt buộc người sử dụng phải giao tiếp một cách hoàn hảo, và không có hệ thống nào có thể phát hiện những xung đột ngữ nghĩa. Vì vậy, khó để bị ru ngủ vào một cảm giác sai về bảo mật rằng một hệ thống khoá bằng cách nào đó ngăn chặn xung đột; trong thực tế, khoá dường như ngăn cản năng xuất nhiều hơn bất cứ thứ gì khác.