Content conflicts vs Property conflicts

On the other hand depending on the situation the conflicts are separated in two categories: Content conflicts and Properties conflicts. Content conflicts - this type refers to the fact that the conflict appears in the content of a file. A merge occurs for every inbound change to a file which is also modified in the working copy. In some cases, if the local change and the incoming change intersect each other, Subversion cannot merge these changes without intervention. So if the conflict is real when updating the file in question the conflicting area is marked like this:

                        <<<<<<< filename
                        your changes
                        code merged from repository
                        >>>>>>> revision

Also, for every conflicted file Subversion places three additional temporary files in your directory:

  • filename.ext.mine - This is your file as it existed in your working copy before you updated your working copy - that is, without conflict markers. This file has your latest changes in it and nothing else.

  • filename.ext.rOLDREV - This is the file that was the BASE revision before you updated your working copy. That is, the file revision that you updated before you made your latest edits.

  • filename.ext.rNEWREV - This is the file that Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.

OLDREV and NEWREV are revision numbers. If you have conflicts with binary files, Subversion does not attempt to merge the files by itself. The local file remains unchanged (exactly as you last changed it) and you will get filename.ext.r* files also. Properties conflicts - refer to the conflicts that are obtained when two people modify the same property of the same file or folder. When updating such a resource a file named filename.ext.prej is created in your working copy containing the nature of the conflict. Your local file property that is in conflict will not be changed. After resolving the conflict one should use the Mark resolved action in order to be able to commit the file. Note that the Mark resolved action does not really resolve the conflict. It just removes the conflicted flag of the file and deletes the temporary files.