SVN Conflict conflict Resolution

Transferred from: http://www.gezila.com/tutorials/17290.html

Directory :

1. Modify file conflicts in the same place

1.1. Solution One

1.2. Solution Two

1.3. Settlement Summary

2. Resolve Conflicts manually

2.1. Conflict background 1

2.2. Conflict Background 2

2.3. Conflict resolution

1. Modify file conflicts in the same place

Developers know that code management tools are an essential tool in development, and this is not a nonsense detail. Whether you personally like git or svn or anything else, there's a lot of companies using SVN as a code-management tool. Here is a detailed description of the solution to the conflict problem when SVN submits the file.

Suppose A, b two users, they checked out the Test1.txt file from the SVN server respectively, at this time a, B, server three places Test1.txt version is 13 (I test the environment of the current SVN-assigned version number). The contents of A and B files are as follows (left a right B):

·

　　

Next, User B adds a sentence and submits the following:

　　

At this point both the B user and the server's version of Test1.txt becomes 14, and only the test1.txt version of the A user is 13. Next, a user adds a "AA" and then submits

　　

Because the a user was modified on version 13 and the server is already version 14, the commit fails:

　　

The next step is to solve the problem, the solution is divided into the following two ways. The first way: After the failure of the submission of the direct selection of revert, eliminating the problem of conflict resolution; The second way: Select Update file after submission failure, there will be conflicting issues. Detailed descriptions are as follows:

1.1. Solution One

A discard its own modified content and perform revert operations to make it test1.txt the initial content of version 13. Then update makes it test1.txt to version 14, and then modifies the commit on version 14. Operations such as:

　　

= = "

　　

==> and then modify the commit

1.2. Solution Two

Because the version is obsolete, the submission fails. A user selects the update operation directly, the result is as seen

　　

(under this statement, do not be confused by the icon displayed in the file, this is the other software related to it caused, no impact)

Here is a detailed look at the following conflict-generating documents:

Test1.txt.mine---This file is a user who made a change in version 13 to submit the file. Its content is: 13 version content +a User's modification

Test1.txt.r13----This file is a user's original version of the 13 test1.txt. Its content is: 13 version content

Test1.txt.r14----This file with the latest version of Test1.txt in the SVN server, which is the 14 version of the B-user submission. Its content is: 13 version content +b User's modification

Test1.txt--------because a user chose direct update, this file is the file that SVN merges with the latest version 14 and a user's modifications. Its content is as follows:

　　

Now let's talk about how to solve it. For source code files or other plain text files, we can organize the content of a user test1.txt, make it meet the criteria, and then select

, then Test.txt.mine, Test1.txt.r13, Test1.text.r14 will disappear. User A will be able to submit it successfully. However, if Test1.txt is a non-plain text file, such as Excel, then the test1.txt will not be able to merge manually and have to discard their own changes. You can right-click on the test1.txt, eliminate the Test.txt.mine, Test1.txt.r13, test1.text.r14 the three files. (clicking Resolve does not change the contents of the Test1.txt and the server side, only the files are eliminated.) At this point the Test1.txt file is ready to be submitted, which corresponds to the latest version of the server, which is version 14 (since this is the result of SVN merging the latest version of server 14 and a user modified content). But this is an illegal file that SVN helped us merge. We can right-click and then select, then Test1.txt will become version 14, a user's modifications are not, a, B, the server test1.txt has become the 14 version. Such as:

　　

Next, a user can then make changes to commit.

1.3. Settlement Summary

For a plain text file due to version outdated submission failure, we can choose to update, and then open the "own changes and the latest version of the server merge" after the file (such as the conflict in the above Test1.txt file), manually merge, processed and then select Resolve and then submit.

For non-plain text files due to version outdated submission failure, we can only sacrifice ourselves, select, and then update to the latest version of the server, and then modify the submission

For example, if Sally modifies a file sandwich.txt, and Harry has just modified the file to the same location and submits it to the server. Then Sally gets three additional files sandwich.txt.mine, SANDWICH.TXT.R1, SANDWICH.TXT.R2 when doing the update operation for this file. And at the time of submission will be rejected by the server, because this file conflict problem has not been resolved. To resolve this conflict, you can choose:

A. Manually merge SVN conflict files (check and modify conflicting flags in the file).

B. Overwrite your working file with a temporary file (one of three).

C. Run the SVN revert to discard all changes.

Once you have resolved your conflict, you need to let subversion know and delete three temporary files by command SVN resolved. Only then can submit.

2. Resolve conflicts manually 2.1. Conflict background 1

　　Let's talk about manually merging SVN conflicts . It's scary at first, but after a while, it's not that annoying.

Look at the following text:

1 Mayonnaise2 lettuce3 Tomato4 provolone5<<<<<<<. Mine6 Salami7 Mortadella8 Prosciutto9=======Ten Sauerkraut One Grilledchicken A>>>>>>>.r2

Creolemustard a series of greater than, less than, equals number is the SVN conflict flag, the data must be deleted before it can be submitted. which

1 <<<<<<<. Mine2salami3mortadella  4prosciutto5 ======= is a change you make in the conflict zone.

1 Sauerkraut 2 Grilledchicken 3 >>>>>>>.r2 is a change made by others in the conflict zone.

In the SVN conflict zone, perhaps you need to communicate with your colleagues to arrange the text of the conflict zone, and if it is a program code, you need to discuss with your colleagues what the middle code should look like.

Once all the conflict zones have been properly resolved, you can submit your documents.

　　Version conflict Reason :

Suppose A, b two users are in the version number 100, the update kingtuns.txt this file, a user after the modification is completed to submit kingtuns.txt to the server, this time the submission is successful, this time Kingtuns.txt file version number has become 101. At the same time, B users in the version number 100 Kingtuns.txt file modification, when the modification is submitted to the server, because it is not in the current version of the latest 101 changes, resulting in the submission failed.

　　Version conflict behavior :

When a conflict occurs, Subversion saves all target file versions in the current working directory [the last updated version, the currently acquired version (that is, the version submitted by someone else), its own updated version, and the target file].

Assume that the file name is Kingtuns.txt

The corresponding filenames are:

1 kingtuns.txt.r101 2 kingtuns.txt.r102 3 Kingtuns.txt.mine 4 Kingtuns.txt.

Also mark changes from different users in the destination file.

2.2. Conflict Background 2

1, now A, b two users are updated Kingtuns.txt files to local.

　　

2. The contents of the original document are as follows:

　　

3, a user to modify the file, add content "A user modified content" after the completion of submission to the server

　　

　　

4, B user Modify the file, add the content "B user Modified content" after the completion of submission to the server

　　

b users are prompted as follows when submitting updates to the server:

　　

b When the user submits the file to the server, it prompts the version to expire: You should first update the version from the repository, then resolve the conflict, perform the SVN resolved (resolution) after the conflict is resolved, and then check in to the repository. After the conflict is resolved, you need to use SVN resolved (resolution) to tell the Subversion conflict resolution so that the update can be submitted.

2.3. Conflict resolution

　　There are three options for resolving conflicts :

A, discard your updates, use SVN revert (rollback), and then submit. In this way you do not need to use SVN resolved (fix)

B. Discard your updates and use someone else's updates. Overwrite the target file with the newly acquired version, execute resolved filename and submit (select File-right-click-Resolve).

C, manual resolution: When a conflict occurs, manually update the target file after communicating with other users. The resolved filename is then executed to remove the conflict and finally commit.

C, manual resolution steps are as follows :

1. Perform an "update" operation in the current directory

　　

2. On the conflicting file ( Select File-Right-click menu-tortoisesvn-edit Conflicts (resolve conflict)), the following window appears

Theirs window is currently the latest version on the server

The mine window is a locally modified version

The merged window is displayed for the merged file contents

　　

3, If you want to use the server version , select the difference in the theirs window, right-click, select the Use this text block (using this paragraph);

　　Similarly, if you want to use the local version , after negotiation, right-click in the Mine window and select Use this text block.

　　

4, after the completion of the modification, save kingtuns.txt file contents.

5, in the conflict directory of the B user, Select File-Right-click menu-tortoisesvn-resolved (Resolve). A list of conflicting files is listed, and if confirmation has been resolved, click OK.

　　

6. Conflict resolution

　　

7. Submit Post-conflict resolution documents.

　　

　　How to reduce the complexity of conflict resolution :

1. When the document is edited and submitted as soon as possible, frequent commits/updates can reduce the probability of conflict occurrence and the complexity of resolving conflicts when they occur.

2, in the submission, write a clear message, convenient to find the reason for the user update, after all, with the passage of time, the reason for the original update may be forgotten

3, develop good usage habits, use SVN each time is first submitted, after the update. After opening every morning, first get the latest version from the repository. Documents that have already been edited must be submitted to the repository every day before they leave work.

SVN Conflict conflict Resolution