svn file conflict, detailed tree conflict

Resolving conflicts
http://blog.csdn.net/sqk1988/article/details/6926745
Occasionally, when you update, merge files from the repository, or switch your working copy to a different URL, you'll run into conflicts. There are two kinds of conflicts:
File conflicts A file conflict
occurs when two (or more) developers modify adjacent or identical lines in the same file.
Tree conflicts
occur when one developer moves, renames, deletes a file or folder and another developer moves, renames, deletes or simply modifies them.
File Conflicts File conflicts
occur when two or more developers modify adjacent or identical lines in the same file. Since Subversion doesn't know the specifics of your project, it leaves conflict resolution to the developer. Once there is a conflict, you should open the file in question and look for lines starting with the string <<<<<<<. Conflicted areas are marked as follows:
<<<<<<< filename
  your changes
=======
  merged from code in the repository
>>>>>> version

for each conflicting file Subversion places three files in your directory:
filename .mine
This is your file that existed in your working copy before you updated your working copy -- that is, no conflict flags. This file has nothing but your latest modifications.
file name.
r revision This is the BASE revision file before you updated your working copy. That is, it is the file that was checked out before you made the last modification.
filename.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 repository.
Assuming that the conflicting file name is aa.java,
you can right-click the file aa.java to open the menu TortoiseSVN → Edit Conflict After opening, the editor will list the conflicting parts with the repository file, you need to determine which code is needed, Make some necessary changes and save.
When we open aa.java again, the <<<<< symbols in it are eliminated, which indicates that the conflict has been resolved.
Then, execute the menu TortoiseSVN → Resolved..., you can submit at this point. Note that "Resolved..." doesn't really resolve the conflict, it just deletes the files filename.ext.mine and filename.ext.r*, allowing you to commit your changes. If you execute "resolved" at the beginning, the file can be submitted, but the conflict in aa.java is still unresolved, and the content is still
<<<<<<< file name
  Your modification
=======
  merged from The code in the repository
>>>>>>> version

So before doing this, be sure to open the menu TortoiseSVN → Edit Conflicts to resolve the conflict and click "Resolved"
If your binaries have conflicts, Subversion will not try to merge the files. The local files remain the same (exactly as they were when you last modified them), but you will see filename.ext.r* files. If you want to undo your changes and keep the version in the repository, use the Revert command. If you want to keep your version overwriting the version in the repository, use the resolved command, then commit your version.
You can use the "Resolved" command to resolve multiple files by right-clicking on the parent folder, selecting TortoiseSVN → Resolved.... This action brings up a dialog that lists all conflicting files in the folder, and you can choose which ones to mark as resolved.
Tree conflicts
occur when one developer moves, renames, deletes a file or folder and another developer moves, renames, deletes or simply modifies them. There are many different situations that can lead to tree conflicts, and different situations require different steps to resolve the conflict.
When a file is deleted natively through Subversion, the file is also deleted from the native file system. So even though it's part of a tree conflict, neither the conflict's overlay icon can be displayed nor the conflict can be resolved by right-clicking. Use the Check for Modifications dialog for editing conflicts options.
TortoiseSVN can assist in finding the right place to merge changes, but requires some extra work to sort out conflicts. Remember: After an update operation, the base file of the working copy will contain the version of each project in the repository at the time of the update operation. If you undo the changes after making the update, the working copy will return to the state of the repository, not the state it was in before you started making the changes.
Delete locally, when an update changes come in
Developer A modifies Foo.c and commits it to the repository
Developer B also renames file Foo.c to Bar.c in his working copy, or just deletes it Foo.c or its parent folder.
Updating developer B's working copy causes a tree conflict:
in the working copy, Foo.c is deleted, but marked as a tree conflict.
If the conflict was due to changing the file name rather than deleting the file, then Bar.c is marked for addition, but it does not include what Developer A modified.
Developer B must now make a choice whether to keep Developer A's changes. In the case of changing the file name, he can merge the changes in Foo.c into the renamed file Bar.c. In the case of deleting a file or folder, he can choose to keep the project with Developer A's changes and forgo the deletion. Or do nothing and just mark the conflict as resolved, so he actually discards developer A's changes.
If TortoiseSVN can find the original file renamed Bar.c, the conflict edit dialog will be able to merge the changes. Depending on where the update operation is called, it may not be able to find the original file.
Local changes, deletes entered when updated
Developer A renames file Foo.c to Bar.c and commits it to the repository.
Developer B modifies the file Foo.c in his working copy.
Or in a folder renaming case...
Developer A renames the parent folder FooFolder to BarFolder and commits it to the repository.
Developer B modifies the file Foo.c in his working copy.
Updating developer B's working copy would cause a tree conflict. 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 produces 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 produces 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 new filename in the repository after the renaming/moving of the conflicting file Foo.c is. You can use the log dialog to accomplish this task. Changes must be merged manually because there is no way to do this automatically or simply. Once the changes are migrated, the conflicting paths are redundant and can be deleted. In this case, use the Delete button in the conflict edit dialog to clean up and mark the conflict as resolved.
If developer B thinks A's changes are wrong, she must select the Keep button in the conflict edit dialog. This marks the conflicting file/folder as resolved, but requires manual removal of Developer A's changes. Again, the log dialog helps keep track of which files have been moved.
Local deletion, when update has deletions in
Developer A renames the file Foo.c to Bar.c and commits it to the repository.
Developer B renames file Foo.c to Bix.c
Updating developer B's working copy causes a tree conflict:
Bix.c is marked for addition (including its history).
Bar.c is added to the working copy with a status of 'OK'.
Foo.c is marked for deletion and produces a tree conflict.
To resolve this conflict, developer B must find out what the new filename in the repository is after the conflicting file Foo.c has been renamed/moved. You can use the log dialog to accomplish this task.
Then, developer B needs to decide which of the new filenames for Foo.c to keep - the one that developer A changed or the one that he changed himself.
After Developer B manually resolves the conflict, use the button in the conflict editing dialog to mark the tree conflict as resolved.
Missing locally, changes come in when merged
Developer A works on trunk, modifies Foo.c and commits it to the repository
Developer B works on branch, renames Foo.c to Bar.c and commits it Into the repository
Merging developer A's trunk changes into developer B's branch working copy would result in a tree conflict:
Bar.c already exists in the working copy with a status of 'OK'.
Foo.c is marked as missing and produces a tree conflict.
To resolve this conflict, developer B marks the file as resolved in the conflict edit dialog, which removes it from the conflict list. She next needs to decide whether to copy the missing file Foo.c from the repository into the working copy, whether to merge Developer A's changes to Foo.c into the renamed Bar.c or whether to conflict by marking it as Resolved to ignore changes and do nothing.
Note that if you copy the missing files from the repository to the working copy and then mark as resolved, the files you copied will be deleted again. You have to resolve the conflict first.
Local changes, when merged with deletes go in
Developer A works on trunk, renames Foo.c to Bar.c and commits it to the repository
Developer B works on branch, modifies Foo.c and commits it To the repository There is a similar case
when the folder is renamed, but it is not recognized in Subversion 1.6...
Developer A works on trunk, renames the parent folder FooFolder to BarFolder and commits it to the repository .
Developer B works on the branch, modifying Foo.c in her working copy.
Merging developer A's trunk changes into developer B's branch working copy results in a tree conflict:
Bar.c is marked for addition.
Foo.c is marked for modification and produces 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 incorporate her native changes into the new layout, Developer B must first find out what the new filename in the repository after the renaming/moving of the conflicting file Foo.c is. This can be done through the log dialog for merging sources. The conflict editor only shows the working copy's log because it doesn't know which path's changes to merge in, so you'll need to find it yourself. Changes must be merged manually because there is no way to do this automatically or simply. Once the changes are migrated, the conflicting paths are redundant and can be deleted. In this case, use the Delete button in the conflict edit dialog to clean up and mark the conflict as resolved.
If developer B thinks A's changes are wrong, she must select the Keep button in the conflict edit dialog. This marks the conflicting file/folder as resolved, but requires manual removal of Developer A's changes. Again, the log dialog helps keep track of which files have been moved.
Local deletes, when merged there are deletes coming in
Developer A works on trunk, renames Foo.c to Bar.c and commits it to the repository
Developer B works on branch, renames Foo.c to Bix .c and commit it to the repository
Merging developer A's trunk changes into developer B's branch working copy results in a tree conflict:
Bix.c is marked in normal (unmodified) state.
Bar.c is marked for addition (including its history).
Foo.c is marked as missing and produces a tree conflict.
To resolve this conflict, developer B must first find out what the new filename in the repository after the renaming/moving of the conflicting file Foo.c is. This can be done through the log dialog for merging sources. The conflict editor only shows the working copy's log because it doesn't know which path's changes to merge in, so you'll need to find it yourself.
Then, developer B needs to decide which of the new filenames for Foo.c to keep - the one that developer A changed or the one that he changed himself.
After Developer B manually resolves the conflict, use the button in the conflict editing dialog to mark the tree conflict as resolved.
About my solution
I encountered this problem, no matter what, I can't delete it. In the end, I had to delete all the local files and re-update the library. Then delete the files you want to delete, and finally submit. This problem no longer occurs.
SVN methods to prevent conflicts:
① Try to divide into multiple classes, and each person is responsible for the development of some classes. ② Update SVN instructions
every day : Update function: Currently I am editing a java file. If I update the entire project at this time, the current Will the edited one be overwritten? the answer is negative.