How svn resolves branch conflicts, and how svn command line resolves conflicts

"So, we need to merge the trunk content into each branch again so that we can continue to develop without problems. ”

You can pull different branches from the current node of the main line. Why merge the main line into branches? Indicates that you do not understand.

A command to resolve version conflicts. After the conflict is resolved, you need to use svn resolved to tell subversion the conflict resolution so that the update can be committed. In the event of a conflict, subversion will save all the object file versions (the last updated version, the currently obtained version, i.e., the version submitted by others, the version updated by itself, and the object file) in the work copy.

Assuming that the file name is, the corresponding file names are: Also mark changes from different users in the target file.

Conflict resolution:

Manual resolution: When a conflict occurs, the target file is manually updated after communicating with other users. Then run the svn resolved filename run to resolve the conflict, and finally commit.

Discard your own updates and use someone else's. Overwrite the target file with the latest obtained version, run the svn resolved filename and commit.

Discard your own update, use svn revert, and commit. In this way, you don't need to use svn resolved.

You need to be very careful with the svn resolved command, you must be very sure that the conflict has been resolved before you can use it. Otherwise, it will cause the subversion to think that the conflict is resolved, and the ** library will be incorrect. Conflict Resolution Detailed Documentation:

If you accidentally submit some files that are not needed for dynamic changes to the svn server, how to resolve the conflict, the basic idea is to first use svn resolved filename to discard the modification of the file, and then you can submit it to the company. Then svn rm deletes the file. Then submit it again, and if someone else updates it, it will be processed in the same way.

ci -m "update"

svn: commit failed (details follow):

svn: aborting commit: '' remains in conflict

2.Use svn resolved

ci -m "update"

At this point, it should be ready to submit.

rm deletes this file.

ci -m "update"

Submit again At this point, the file is no longer available on the server.

Repeat this operation on other server terminals if you encounter this problem. Hope.

Method steps.

Many situations will occur in team development, so let's explain the applications in SVN one by one and how to solve them when they encounter them. There must be SVN installed in MyEclipse, which can be installed or offline.

The project must be checked out in svn.,And it's been modified.,Whether it's modified by others or modified by yourself.,So you can see if there's a difference.,Then right-click on the project to find the team's synchronization with the resource library.,So that you can enter the synchronization interface.,Let's start analyzing from here.。

The most important thing on the way to Biyeheng is to analyze the things in this area.

Analysis: The first icon is resync, if someone else submits a file during your synchronization process, then clicking on this spine will resync; Second: the one with a plus sign is whether you have added the file yourself, if there is an added file, a plus icon will appear, and the minus sign will be the same, if you delete the file, there will be a minus sign on the same diagram.

Third: the blue icon is something that someone else has submitted; Fourth: I think the gray arrow on the right is what you want to submit or modify; Fifth:

If it's all; And the sixth red arrow is that someone else's stuff has been changed to the same place as the stuff you submitted.

In fact, the red arrow needs to be processed, this is the need to double-click the file, if there is no red area in the two file areas, then it can be updated directly, and then in the commit, regret that if there is a red area, you need to resolve the conflict, you can change what you wrote to other lines, so that there will be no conflict, or the two changes can be connected.

If two people change the same version of the same file, the latter person will definitely be prompted to find a conflict when committing or updating, and similarly with branch merge, a conflict will be found.

SVN branch merging is simply a matter of taking a version of a folder you specify in the SVN repository and comparing it with a local folder you specify, and then transferring the difference to your local folder.

Regarding the use of branch merging, for example, according to the official recommendation of SVN, the root directory of an SVN repository will be divided into three subfolders: trunk, branches, and tags. Among them, trunk is used to store the ** that is constantly added, modified, and committed. When the development reaches a certain level and a round of testing is required, in order to avoid mutual interference between development and test bug fixing, pull a branch from the trunk (copy a current image) to the test001 folder under branches, and all defect fixes are modified and committed in the test001 folder under branches.

When this round of testing and bug fixes are completed, and then all the changes in the test001 folder are merged into the trunk, then the branch merge function completes the following things: compare the latest version of the test001 folder on the SVN server with your local client trunk folder, if there is no conflict, overwrite the modified files in test001 to the corresponding files in your local client trunk, and then perform the commit operation by yourself again. If a conflict is found, a conflict has occurred and the merge has failed.

Now that you understand what the branch merge function does, I think you will understand the difference between it and commit update.