Manuals

Mô hình Phiên bản

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

Vấn đề chia sẻ tập tin

Hãy xem xét kịch bản này: giả sử chúng ta có hai đồng nghiệp, Harry và Sally. Mỗi quyết định chỉnh sửa các tập tin kho lưu trữ tại cùng một thời gian. Nếu Harry lưu thay đổi của mình vào kho lưu trữ đầu tiên, có thể một vài khoảnh khắc sau đó Sally vô tình có thể ghi đè lên chúng với phiên bản mới của tập tin. Trong khi Harry phiên bản của tập tin sẽ không bị mất mãi mãi (do hệ thống nhớ mỗi lần thay đổi), bất kỳ thay đổi nào Harry đã thực hiện sẽ không có mặt trong phiên bản mới hơn của Sally của tập tin, bởi vì cô không bao giờ nhìn thấy những thay đổi để bắt đầu với Harry. Tác phẩm của Harry vẫn còn có hiệu quả bị mất hoặc ít nhất là mất tích từ các phiên bản mới nhất của tập tin - và có lẽ do tai nạn. Điều này chắc chắn là một tình huống mà chúng ta muốn tránh!

Hình 2.2. Vấn đề cần tránh

Vấn đề cần tránh

Giải pháp Khóa-Sửa-Mở khóa

Nhiều phiên bản kiểm soát hệ thống sử dụng một mô hình khoá-thay đổi-mở khóa để giải quyết vấn đề này, mà là một giải pháp rất đơn giản. Trong hệ thống như vậy, kho lưu trữ chỉ cho phép một người thay đổi một tập tin tại một thời điểm. Đầu tiên Harry phải khóa các tập tin trước khi có thể bắt đầu thay đổi nó. Khóa một tập tin là rất giống như mượn một cuốn sách từ thư viện, nếu Harry đã khóa một tập tin, thì sau đó Sally không thể thực hiện bất kỳ thay đổi với nó. Nếu cô ấy cố gắng để khóa các tập tin, các kho lưu trữ sẽ từ chối yêu cầu. Tất cả những gì có thể làm là đọc các tập tin, và chờ đợi cho Harry để kết thúc những thay đổi của mình và phát hành khóa của mình. Sau khi Harry mở các tập tin, hết lượt của mình, và bây giờ Sally có thể lần lượt của mình bằng cách khóa và chỉnh sửa.

Hình 2.3. Giải pháp Khóa-Sửa-Mở khóa

Giải pháp Khóa-Sửa-Mở khóa

Vấn đề với mô hình khóa, sửa đổi, mở khóa là nó có một chút hạn chế, và thường trở thành một rào cản cho người sử dụng:

  • Khóa có thể gây ra các vấn đề hành chính. Đôi khi Harry sẽ khóa một tập tin và sau đó quên nó. Trong khi đó, bởi vì Sally là vẫn đang chờ đợi để chỉnh sửa các tập tin, bàn tay của cô bị bó buộc. Và sau đó Harry đi vào kỳ nghỉ. Bây giờ Sally phải nhờ một quản trị viên để phát hành khóa của Harry. Tình hình kết thúc lên gây ra rất nhiều sự chậm trễ không cần thiết và lãng phí thời gian.

  • Khóa có thể gây ra tuần tự không cần thiết. Nếu Harry là chỉnh sửa bắt đầu của một tập tin văn bản, và Sally chỉ đơn giản là muốn chỉnh sửa cuối cùng một tập tin? Những thay đổi này không chồng chéo lên nhau chút nào. Họ có thể dễ dàng chỉnh sửa các tập tin cùng một lúc, và không có hại lớn, giả sử những thay đổi sáp nhập với nhau đúng cách. Không cần cho họ phải thay phiên nhau trong tình huống này.

  • Khóa có thể tạo ra một cảm giác an toàn sai lầm. Giả vờ rằng Harry khóa và chỉnh sửa tập tin A, trong khi đồng thời Sally khóa và chỉnh sửa các tập tin B. Nhưng giả sử rằng A và B phụ thuộc vào nhau, và các thay đổi được thực hiện cho từng ngữ nghĩa không tương thích. Đột nhiên A và B không làm việc cùng nhau nữa. Hệ thống khóa bất lực để ngăn chặn vấn đề nhưng nó bằng cách nào đó cung cấp một cảm giác an toàn sai. Thật dễ dàng cho Harry và Sally để tưởng tượng rằng các tập tin khóa, mỗi bắt đầu một công việc an toàn, cách biệt, và do đó ức chế sự thảo luận về những thay đổi không tương thích của họ sớm hơn.

Giải pháp Sao chép-Sửa đổi-Hợp nhất

Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

Dưới đây là một ví dụ. Hãy nói rằng Harry và Sally đều tạo ra các bản sao làm việc cùng một dự án, sao chép từ kho. Họ làm việc đồng thời, và thay đổi cùng một tập tin A trong bản sao của họ. Sally lưu thay đổi của mình vào kho lưu trữ đầu tiên. Khi Harry cố gắng để lưu các thay đổi của ông sau đó, kho lưu trữ thông báo cho ông rằng tập tin của mình quá cũ . Nói cách khác, tập tin A đó trong kho lưu trữ bằng cách nào đó thay đổi kể từ khi ông mới sao chép nó. Vì vậy, Harry yêu cầu khách hàng của mình để hợp nhất bất kỳ thay đổi mới nhất từ ​​kho vào bản sao hoạt động của tập tin A. Có thể là những thay đổi của Sally không chồng chéo lên nhau với bản của riêng ông ta, do đó, một khi ông có cả bộ những thay đổi tích hợp, ông lưu bản sao làm việc của mình trở lại vào kho.

Hình 2.4. Giải pháp Sao chép-Sửa đổi-Hợp nhất

Giải pháp Sao chép-Sửa đổi-Hợp nhất

Hình 2.5. ... Sao chép-Sửa đổi-Hợp nhất Tiếp theo

... Sao chép-Sửa đổi-Hợp nhất Tiếp theo

Nhưng điều gì sẽ xảy ra nếu thay đổi của Sally làm trùng với thay đổi của Harry? Những gì sau đó? Tình trạng này được gọi là một xung đột , Và nó thường là không phải là một vấn đề gì nhiều. Khi Harry yêu cầu khách hàng của mình để hợp nhất các thay đổi kho lưu trữ mới nhất vào bản sao làm việc của mình, bản sao của tập tin A là bằng cách nào đó gắn cờ là trong trạng thái xung đột: anh ta sẽ có thể nhìn thấy cả hai bộ những thay đổi xung đột, và tự lựa chọn giữa chúng . Lưu ý rằng phần mềm có thể không tự động giải quyết xung đột, con người chỉ có khả năng hiểu biết và thực hiện những lựa chọn thông minh cần thiết. Khi Harry đã giải quyết thủ công những thay đổi chồng chéo (có lẽ bằng cách thảo luận về cuộc xung đột với Sally), ông một cách an toàn có thể lưu các tập tin bị sáp nhập trở lại vào kho.

Mô hình sao chép, sửa đổi, sáp nhập có thể nghe một chút hỗn loạn, nhưng trong thực tế, nó chạy rất trơn tru. Người dùng có thể làm việc song song, không bao giờ chờ đợi nhau. Khi họ làm việc trên các tập tin tương tự, nó hóa ra rằng hầu hết các thay đổi đồng thời của họ không chồng chéo lên nhau ở tất cả các xung đột hiếm khi xảy ra. Và số lượng thời gian cần thiết để giải quyết xung đột là ít hơn so với thời gian đã mất bằng một hệ thống khóa.

Cuối cùng, nó đi xuống đến một yếu tố quan trọng: người sử dụng thông tin liên lạc. Khi người sử dụng giao tiếp kém, cả hai cú pháp và ngữ nghĩa xung đột gia tăng. Không có hệ thống có thể buộc người dùng để giao tiếp hoàn hảo, và không có hệ thống có thể phát hiện xung đột ngữ nghĩa. Vì vậy, không có điểm bị đẩy vào một lời hứa sai lầm rằng một hệ thống khóa bằng cách nào đó sẽ ngăn chặn xung đột, trong thực tế, khóa có vẻ ức chế năng suất hơn bất cứ điều gì khác.

Có một tình hình phổ biến nơi mô hình khóa-sửa đổi-mở khóa cho kết quả tốt hơn, và đó là nơi mà bạn có các tập tin không hợp nhất được. Ví dụ, nếu kho lưu trữ của bạn có chứa một số hình ảnh đồ họa, và hai người thay đổi hình ảnh tại cùng một thời gian, không có cách nào cho những thay đổi được sáp nhập với nhau. Hoặc là Harry hoặc Sally sẽ mất các thay đổi.

Subversion làm gì?

Subversion sử dụng các bản sao chỉnh sửa, kết hợp giải pháp theo mặc định, và trong nhiều trường hợp này là tất cả những gì mà bạn cần. Tuy nhiên, phiên bản 1.2, Subversion cũng hỗ trợ các khóa tập tin, vì vậy nếu bạn có các tập tin không hợp nhất được, hoặc nếu bạn chỉ đơn giản là bị ép buộc vào một chính sách khóa bởi ban quản lý, Subversion vẫn sẽ cung cấp các tính năng bạn cần.

TortoiseSVN homepage