2015-01-19 21 views
17

Tôi đang cố gắng tìm hiểu kiến ​​thức cơ bản về kiểm soát phiên bản của Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdfGiải quyết xung đột hợp nhất khi tôi cập nhật svn

Tôi đang ở trang 22 bây giờ. Tôi sẽ mô tả kịch bản cho bạn. Hai người dùng trên cùng một máy tính, harry và sally đang làm việc trên một tệp có tên là xổ số.c được lưu trữ trong một repo có tên là xổ số.

1 - Harry cam kết mã đầu tiên/đầu tiên. 2 - Sally thay đổi và cam kết. 3 - Trong khi 2 đang xảy ra, harry đã thực hiện thay đổi nhưng không cam kết. 4 - Harry cam kết và gặp lỗi.

Transmitting file data .svn: Commit failed (details follow): 
svn: File '/lottery.c' is out of date 

5 - Để khắc phục điều này, hãy cập nhật bản sao cục bộ của mình bằng cách sử dụng svn update.

Đây là nơi tôi gặp sự cố! Tác giả nói ra là:

lottery harry$ svn update 
G lottery.c 
Updated to revision 2. 

Nhưng, đầu ra của tôi là:

lottery harry$ svn update 
Updating '.': 
C lottery.c 
Updated to revision 2. 
Conflict discovered in file 'lottery.c'. 
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, 
     (mc) my side of conflict, (tc) their side of conflict, 
     (s) show all options: 

Tôi mới và tôi không biết làm thế nào để đáp ứng với thông báo này. Cuốn sách của tôi có sai không? Làm ơn giúp tôi. Cảm ơn.

+0

Tôi đang sử dụng tc cho bây giờ. Tôi đoán đó là những gì tác giả có thể có ý nghĩa. – Steam

Trả lời

30

Khi bạn có nhiều người thay đổi cùng một tệp cùng một lúc, có thể cả hai thay đổi cùng một dòng. Đây là những gì đã xảy ra với bạn. Sally thay đổi cùng một dòng mà Harry đang thay đổi. Khi Harry thực hiện svn update, Subversion đã phát hiện ra điều này và yêu cầu bạn phải làm gì.

Cảnh báo: Đôi khi Subversion chỉ tìm kiếm sự khác biệt trong một dòng giữa phiên bản và phiên bản của họ chứ không phải khác biệt có ý nghĩa. Ví dụ, nếu thụt lề của một dòng đã được thay đổi, hoặc khoảng cách là khác nhau, hoặc nếu bạn thay đổi kết thúc dòng, Subversion sẽ tuyên bố điều này như là một cuộc xung đột mặc dù nó có thể không phải là. Điều này có thể lý do tại sao cuốn sách không tìm thấy vấn đề này, nhưng bạn đã làm. Không có nghĩa là bạn đã làm gì sai.

Việc cần làm? Subversion đang cung cấp cho bạn một vài lựa chọn.

  • hoãnp: Đây là những gì tôi thường làm với loại tình huống.Subversion sẽ nhúng trong file dấu diff mà trông như thế này trong các tập tin:

 

<<<<<<< .mine 
foobar 
======= 
fubar 
>>>>>>> .rxxx 

này được hiển thị cho bạn những thay đổi trong phiên bản rxxx (những gì Sally đã) trông giống như vs. những thay đổi bạn có (những thay đổi của Harry). Thông thường, những thay đổi là đủ nhỏ mà nó khá dễ dàng để tìm ra phải làm gì.

  • chương trình diffdf: Điều này sẽ cho bạn thấy sự khác biệt giữa các thay đổi của bạn (Harry) và những gì trong phiên bản khác (Sally). Về cơ bản nó cho bạn thấy các điểm đánh dấu khác.
  • chỉnh sửae: Bạn có thể chỉnh sửa xung đột hợp nhất khi bạn hợp nhất thay vì đợi đến sau.
  • hợp nhấtm: Không quá chắc chắn về điều này. Bạn đang thực hiện hợp nhất ngay bây giờ, vì vậy điều này không có ý nghĩa quá nhiều.
  • bên cạnh tranh của họtc: Chấp nhận những gì Sally đã làm để giải quyết xung đột. Bạn có thể phải làm lại các thay đổi của bạn, nhưng ít nhất bạn đang xem xét những thay đổi của Sally.
  • bên cạnh tranh của tôimc: Trường hợp nguy hiểm nhất vì bạn hoàn toàn bỏ qua những thay đổi của Sally. Sally đã sửa chữa, và bạn có thể tháo nó ra. Khi bản phát hành được phát hành và bản sửa lỗi của Sally không có trong đó, bạn sẽ bị đổ lỗi cho việc xóa thay đổi. Vì vậy, tại sao bạn làm điều này? Bởi vì bạn đã xem xét những thay đổi, và nhận ra cuộc xung đột thực sự không có nhiều xung đột. Đó là một sự thay đổi trong thụt đầu dòng hoặc một cái gì đó tương tự. Hoặc bạn đã gọi biến số increment và Sally gọi nó là counter.

Như tôi đã nói, tôi thường làm hoãn, để bản cập nhật của tôi kết thúc, sau đó xử lý sự cố.

Sau khi khắc phục sự cố, bạn thực hiện svn resolved trên tệp đó để cho Subversion biết bạn đã khắc phục xung đột.

Có nhiều lựa chọn hơn - ví dụ: bạn có thể khởi chạy công cụ khác biệt/hợp nhất của bên thứ ba để xử lý xung đột.

Để biết thêm thông tin, hãy xem hướng dẫn sử dụng Subversion trên dòng về resolving merge conflicts.

1

Chữ "G" cho biết tệp đã được sửa đổi bởi người khác, nhưng sửa đổi mà người đó đã ở trong một phần khác của tệp, vì vậy SVN có thể hợp nhất nó cho bạn mà không yêu cầu trợ giúp.

Chữ "C" chỉ ra rằng không chỉ là tệp được sửa đổi bởi người khác, mà thay đổi của chúng cũng giống với các dòng bạn cũng thay đổi, vì vậy SVN không biết phải làm gì. Bây giờ nó là công việc của BẠN để làm việc hợp nhất.

Bạn có thể không làm điều gì sai trái, và cuốn sách không sai, họ chỉ để lại chi tiết về những thay đổi cụ thể, rõ ràng.

4

Nếu bạn chọn tùy chọn s nó sẽ cho bạn thấy:

(e) edit    - change merged file in an editor 
(df) diff-full  - show all changes made to merged file 
(r) resolved   - accept merged version of file 

(dc) display-conflict - show all conflicts (ignoring merged version) 
(mc) mine-conflict - accept my version for all conflicts (same) 
(tc) theirs-conflict - accept their version for all conflicts (same) 

(mf) mine-full  - accept my version of entire file (even non-conflicts) 
(tf) theirs-full  - accept their version of entire file (same) 

(p) postpone   - mark the conflict to be resolved later 
(l) launch   - launch external tool to resolve conflict 
(s) show all   - show this list 

Sử dụng dc để xem các confilicts sau đó bạn có thể quyết định việc lựa chọn tốt nhất để sử dụng

Các vấn đề liên quan