SVN file conflict, tree conflict detailed

Resolve Conflicts

Occasionally, you encounter conflicts when you update from a version library, merge files, or switch working copies to a different URL. There are two types of conflicts: file conflicts

File conflicts occur when two (or more) developers modify a row that is adjacent or identical in the same file. Tree conflict

A tree conflict occurs when a developer moves, renames, deletes a file or folder, and another developer moves, renames, deletes, or simply modifies it. file Conflicts

File conflicts occur when two or more developers modify a row that is adjacent or identical in the same file. Because Subversion does not know the specifics of your project, it leaves the work of conflict resolution to the developers. In the event of a conflict, you should open the problematic file and look for a line that starts with a string <<<<<<<. Areas with conflicts are marked in the following way:

<<<<<<< file name
Your modifications.
=======
Merging code from a version library
>>>>>>> version

For each conflicting file Subversion placed three files in your directory: file name. mine

This is your file, which exists in your working copy before you update your working copy-that is, there are no conflicting flags. There is nothing else in this file except your latest modification. File name. R version

This is the underlying version (base revision) file before you update your working copy. In other words, it is the file that was checked out before you made the final change. File name. R new Version

This file is received by your Subversion client from the server when you update your working copy. This file corresponds to the latest version in the version library.

Suppose the file name of the conflict is Aa.java

You can right-click on the file Aa.java Open menu tortoisesvn→ edit conflict Open, the editor will be listed with the version of the Library file Conflict section, you need to flush which code is needed, make some necessary changes and then save.

When we open the Aa.java again, the inside of the <<<<< symbol is eliminated, which indicates that the conflict has been resolved.

Then, execute the menu tortoisesvn→ resolved ..., and then you can submit it now. Note that "resolved ..." is not really a solution to the conflict, it just deletes the filename.ext.mine and filename.ext.r* two files and allows you to submit changes. If "Resolved" is executed at the beginning, the file can be submitted, but the conflict in the Aa.java is still unresolved and the content is

<<<<<<< file name
Your modifications.
=======
Merging code from a version library
>>>>>>> version

So be sure to open the menu before that. tortoisesvn→ edit conflict resolved and then click "Resolved"

If your binaries are conflicting, subversion will not attempt to merge the files. The local file stays the same (exactly the way you last modified it), but you'll see the filename.ext.r* file. If you want to undo your changes and keep the version in the library, use the Restore (Revert) command. If you want to keep your version covered in the version library version, use the resolved command and then submit your version.

You can right-click the parent folder, select tortoisesvn→ resolved ..., use the resolved command to resolve multiple files. This action will appear with a dialog box listing all the conflicting files under the folder, and you can choose which ones to mark as resolved. Tree Conflict

A tree conflict occurs when a developer moves, renames, deletes a file or folder, and another developer moves, renames, deletes, or simply modifies it. There are many different situations that can cause tree conflicts, and different situations require different steps to resolve the conflict.

When a file is deleted by Subversion on this computer, the file is also removed from the native file system. Therefore, even if it is part of a tree conflict, it can neither display conflicting superimposed icons nor resolve conflicts by right-clicking. Use the Check Modify dialog box to get edit conflict options.

TortoiseSVN can help find the correct location for the merged changes, but some extra work needs to be done to organize the conflict. Keep in mind that after an update operation, the base file for the working copy will include the version of each project in the version library when the update operation is performed. If you undo the change after the update is made, the working copy will return to the status of the version library, not the state before you start making the changes. local deletion, when updated with changes entered

Developer A modifies the FOO.C and submits it to the version library

Developer B also renamed the file foo.c to bar.c in his working copy, or simply deleted FOO.C or its parent folder.

Updating the working copy of developer B can cause tree conflicts:

In the working copy, the FOO.C is deleted, but is marked as a tree conflict.

If the conflict is caused by changing the file name rather than deleting the file, then BAR.C is marked for addition, but it does not include what developer A modifies.

Developer B must now make a choice whether to retain developer A's changes. In the case of changing the filename, he can merge the foo.c changes into the renamed file BAR.C. In cases where a file or folder is deleted, he can choose to keep the item that contains developer A changes and discard the deletion. Or do nothing and directly mark the conflict as resolved, so that he actually discards developer A's changes.

If TortoiseSVN can find the original file that was renamed BAR.C, the Conflict Editing dialog box will be able to merge the changes. Depending on where the update operation is invoked, it may not be able to find the original file. local changes, when updated with delete entry

Developer A renamed the file foo.c to BAR.C and submitted it to the version library.

Developer B modifies the file foo.c in his working copy.

Or in the case of a folder name change ...

Developer A renames the parent folder Foofolder to Barfolder and submits it to the version library.

Developer B modifies the file foo.c in his working copy.

Updating the working copy of developer B can cause tree conflicts. For a simple file conflict:

BAR.C is added to the working copy as a normal file.

FOO.C is marked for addition (including its history) and creates a tree conflict.

For a folder conflict:

Barfolder is added to the working copy as a normal folder.

Foofolder is marked for addition (including its history) and creates a tree conflict.

FOO.C is marked as modified.

Developer B now needs to decide whether to accept the structural changes made by developer A and merge her changes into the appropriate files under the new structure, or simply discard developer A's changes and keep the local files.

To merge her native changes into the new layout, developer B must first find out what the conflicting files foo.c the new file name in the version library after renaming/moving. You can use the Log dialog box to complete this task. Changes must be merged manually because there is no way to do this automatically or simply. Once the changes have been migrated, the path to the conflict is redundant and can be deleted. In this case, use the Delete button in the Conflict Editing dialog box to clean up and mark the conflict as resolved.

If developer B thinks the change of a is wrong, she must select the retention button in the Conflict Editing dialog box. This will mark the conflicting files/folders as resolved, but you will need to manually delete developer A's changes. It is also through the Log dialog box to help track which files have moved. Local Delete, when updated with delete entry

Developer A renamed the file foo.c to BAR.C and submitted it to the version library.

Developer B renamed the file foo.c to bix.c

Updating the working copy of developer B can cause tree conflicts:

BIX.C is marked for addition (including its history).

BAR.C is added to the working copy, and its status is ' normal '.

FOO.C is marked for deletion and a tree conflict is generated.

To resolve this conflict, developer B must find out what the new file name in the version library foo.c after renaming/moving. You can use the Log dialog box to complete this task.

Then developer B needs to decide which of the new file names in FOO.C needs to be retained-the one that developer A changed or the one he changed.

After developer B manually resolves the conflict, use the buttons in the Conflict Editing dialog box to mark the tree conflict as resolved. local missing, changes are entered when merging

Developer A works on the backbone, modifies the foo.c and submits it to the version library

Developer B works on the branch, renaming FOO.C to BAR.C and submitting it to a version library

The skeleton of the merged developer A Change to a branch working copy of developer B causes a tree conflict:

Bar.c already exists in the working copy and has a status of ' normal '.

FOO.C is marked as missing and produces a tree conflict.

To resolve this conflict, developer B will remove it from the conflict list by marking the file as resolved in the Conflict Editing dialog box. She then needs to decide whether to copy the missing files foo.c from the version library to the working copy, whether to ignore changes made by developer A to the foo.c and merge to the renamed BAR.C or whether the change has been resolved by marking conflicts to nothing.

Note that if you copy the missing files from the repository to the working copy and then mark them as resolved, the files you have copied will be deleted again. You must resolve the conflict first. local changes, when merging with delete entry

Developer A works on the backbone, renaming foo.c to BAR.C and submitting it to a version library

Developer B works on the branch, modifies the FOO.C and submits it to the version library

There were similar cases when the folder was renamed, but it was not recognized in Subversion 1.6 ...

Developer A works on the backbone, renaming the parent folder Foofolder to Barfolder and submitting it to the version library.

Developer B works on the branch and modifies the foo.c in her working copy.

The skeleton of the merged developer A Change to a branch working copy of developer B causes a tree conflict:

BAR.C is marked for addition.

FOO.C is marked for modification and creates a tree conflict.

Developer B now needs to decide whether to accept the structural changes made by developer A and merge her changes into the appropriate files under the new structure, or simply discard developer A's changes and keep the local files.

To merge her native changes into the new layout, developer B must first find out what the conflicting files foo.c the new file name in the version library after renaming/moving. You can do this by using a Log dialog box that applies to the merged source code. The conflict editor only displays the log of a working copy because it doesn't know which path changes to merge into, so you need to find it yourself. Changes must be merged manually because there is no way to do this automatically or simply. Once the changes have been migrated, the path to the conflict is redundant and can be deleted. In this case, use the Delete button in the Conflict Editing dialog box to clean up and mark the conflict as resolved.

If developer B thinks the change of a is wrong, she must select the retention button in the Conflict Editing dialog box. This will mark the conflicting files/folders as resolved, but you will need to manually delete developer A's changes. It is also through the Log dialog box to help track which files have moved. local deletion, when merging with delete entry

Developer A works on the backbone, renaming foo.c to BAR.C and submitting it to a version library

Developer B works on a per cent, renaming foo.c to BIX.C and submitting it to a version library

The skeleton of the merged developer A Change to a branch working copy of developer B causes a tree conflict:

The bix.c is marked as a normal (unmodified) state.

BAR.C is marked for addition (including its history).

FOO.C is marked as missing and creates a tree conflict.

To resolve this conflict, developer B must first identify the conflicting files foo.c the new file name in the version library after renaming/moving. You can do this by using a Log dialog box that applies to the merged source code. The conflict editor only displays the log of a working copy because it doesn't know which path changes to merge into, so you need to find it yourself.

Then developer B needs to decide which of the new file names in FOO.C needs to be retained-the one that developer A changed or the one he changed.

After developer B manually resolves the conflict, use the buttons in the Conflict Editing dialog box to mark the tree conflict as resolved.

About My Solution
I encountered this problem, no matter how kind can not be deleted. Finally, you have to delete all the local files and update the library again. Then delete the file you want to delete, and then submit it. There is no such problem.

SVN ways to prevent conflicts:

① as far as possible will be divided into multiple classes, each person responsible for a number of class development

② Daily Update SVN usage instructions: Update function: Currently I am editing a Java file, if I update the entire project at this time, the current edit will be overwritten. The answer is in the negative.