Once in a while, you will get a conflict when you update/merge your files from the repository or when you switch your working copy to a different URL. There are two kinds of conflicts:
A file conflict occurs if two (or more) developers have changed the same few lines of a file.
A tree conflict occurs when a developer moved/renamed/deleted a file or folder, which another developer either also has moved/renamed/deleted or just modified.
A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. Whenever a conflict is reported, you should open the file in question, and search for lines starting with the string <<<<<<<. The conflicting area is marked like this:
<<<<<<< filename your changes ======= code merged from repository >>>>>>> revision
Also, for every conflicted file Subversion places three additional files in your directory:
Ini adalah file Anda karena ia ada dalam copy pekerjaan Anda sebelum Anda memutahirkan copy pekerjaan Anda - yakni, tanpa tanda konflik. File ini mempunyai perubahan terakhir di dalamnya dan tidak ada yang lain.
Ini adalah file daru revisi BASE sebelum Anda memutahirkan copy pekerjaan Anda. Yaitu file yang Anda check out sebelum Anda membuat pengeditan terakhir.
Ini adalah file dimana klien Subversion Anda menerimanya dari server ketika Anda memutahirkan copy pekerjaan Anda. File ini terkait ke revisi HEAD dari repositori.
Anda bisa menjalankan piranti editor gabung/konflik eksternal dengan → atau Anda bisa menggunakan editor lain untuk menyelesaikan konflik secara manual. Anda harus memutuskan seperti apa kode seharusnya terlihat, lakukan perubahan yang diperlukan dan simpan file.
Selanjutnya jalankan perintah → dan komit modifikasi Anda ke repositori. Harap dicatat bahwa perintah Selesaikan tidak benar-benar menyelesaikan konflik. Ia hanya menghapus file filename.ext.mine dan filename.ext.r*, untuk membolehkan Anda mengkomit perubahan Anda.
Jika Anda mempunyai konflik dengan file biner, Subversion tidak mencoba untuk menggabung file itu sendiri. File lokal tetap tidak diubah (persis seperti perubahan terakhir Anda) dan Anda mempunyai file filename.ext.r*. Jika Anda ingin mengabaikan perubahan Anda dan membiarkan versi repositori, cukup gunakan perintah Pulihkan. Jika Anda ingin memelihara versi Anda dan menimpa versi repositori, gunakan perintah Diselesaikan, lalu komit versi Anda.
Anda bisa menggunakan perintah Diselesaikan untuk multipel file jika Anda mengklik kanan pada folder leluhur dan memilih → Ini akan memunculkan dialog yang mendaftarkan semua file yang konflik dalam folder itu, dan Anda bisa memilih yang mana untuk ditandai sebagai diselesaikan.
A tree conflict occurs when a developer moved/renamed/deleted a file or folder, which another developer either also has moved/renamed/deleted or just modified. There are many different situations that can result in a tree conflict, and all of them require different steps to resolve the conflict.
When a file is deleted locally in Subversion, the file is also deleted from the local file system, so even if it is part of a tree conflict it cannot show a conflicted overlay and you cannot right click on it to resolve the conflict. Use the Check for Modifications dialog instead to access the Edit conflicts option.
TortoiseSVN can help find the right place to merge changes, but there may be additional work required to sort out the conflicts. Remember that after an update the working BASE will always contain the revision of each item as it was in the repository at the time of update. If you revert a change after updating it goes back to the repository state, not to the way it was when you started making your own local changes.
Developer A modifies Foo.c and commits it to the repository
Developer B has simultaneously moved Foo.c to Bar.c in his working copy, or simply deleted Foo.c or its parent folder.
An update of developer B's working copy results in a tree conflict:
Foo.c has been deleted from working copy, but is marked with a tree conflict.
If the conflict results from a rename rather than a delete then Bar.c is marked as added, but does not contain developer A's modifications.
Developer B now has to choose whether to keep Developer A's changes. In the case of a file rename, he can merge the changes to Foo.c into the renamed file Bar.c. For simple file or directory deletions he can choose to keep the item with Developer A's changes and discard the deletion. Or, by marking the conflict as resolved without doing anything he effectively discards Developer A's changes.
The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. Depending on where the update was invoked, it may not be possible to find the source file.
Developer A moves Foo.c to Bar.c and commits it to the repository.
Developer B modifies Foo.c in his working copy.
Or in the case of a folder move ...
Developer A moves parent folder FooFolder to BarFolder and commits it to the repository.
Developer B modifies Foo.c in his working copy.
An update of developer B's working copy results in a tree conflict. For a simple file conflict:
Bar.c is added to the working copy as a normal file.
Foo.c is marked as added (with history) and has a tree conflict.
For a folder conflict:
BarFolder is added to the working copy as a normal folder.
FooFolder is marked as added (with history) and has a tree conflict.
Foo.c is marked as modified.
Developer B now has to decide whether to go with developer A's reorganisation and merge her changes into the corresponding file in the new structure, or simply revert A's changes and keep the local file.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted. In this case use the Remove button in the conflict editor dialog to clean up and mark the conflict as resolved.
If Developer B decides that A's changes were wrong then she must choose the Keep button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.
Developer A moves Foo.c to Bar.c and commits it to the repository
Developer B moves Foo.c to Bix.c
An update of developer B's working copy results in a tree conflict:
Bix.c is marked as added with history.
Bar.c is added to the working copy with status 'normal'.
Foo.c is marked as deleted and has a tree conflict.
To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog.
Then developer B has to decide which new filename of Foo.c to keep - the one done by developer A or the rename done by himself.
After developer B has manually resolved the conflict, the tree conflict has to be marked as resolved with the button in the conflict editor dialog.
Developer A working on trunk modifies Foo.c and commits it to the repository
Developer B working on a branch moves Foo.c to Bar.c and commits it to the repository
A merge of developer A's trunk changes to developer B's branch working copy results in a tree conflict:
Bar.c is already in the working copy with status 'normal'.
Foo.c is marked as missing with a tree conflict.
To resolve this conflict, Developer B has to mark the file as resolved in the conflict editor dialog, which will remove it from the conflict list. She then has to decide whether to copy the missing file Foo.c from the repository to the working copy, whether to merge Developer A's changes to Foo.c into the renamed Bar.c or whether to ignore the changes by marking the conflict as resolved and doing nothing else.
Note that if you copy the missing file from the repository and then mark as resolved, your copy will be removed again. You have to resolve the conflict first.
Developer A working on trunk moves Foo.c to Bar.c and commits it to the repository
Developer B working on a branch modifies Foo.c and commits it to the repository.
There is an equivalent case for folder moves, but it is not yet detected in Subversion 1.6 ...
Developer A working on trunk moves parent folder FooFolder to BarFolder and commits it to the repository.
Developer B working on a branch modifies Foo.c in her working copy.
A merge of developer A's trunk changes to developer B's branch working copy results in a tree conflict:
Bar.c is marked as added.
Foo.c is marked as modified with a tree conflict.
Developer B now has to decide whether to go with developer A's reorganisation and merge her changes into the corresponding file in the new structure, or simply revert A's changes and keep the local file.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted. In this case use the Remove button in the conflict editor dialog to clean up and mark the conflict as resolved.
If Developer B decides that A's changes were wrong then she must choose the Keep button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.
Developer A working on trunk moves Foo.c to Bar.c and commits it to the repository
Developer B working on a branch moves Foo.c to Bix.c and commits it to the repository
A merge of developer A's trunk changes to developer B's branch working copy results in a tree conflict:
Bix.c is marked with normal (unmodified) status.
Bar.c is marked as added with history.
Foo.c is marked as missing and has a tree conflict.
To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself.
Then developer B has to decide which new filename of Foo.c to keep - the one done by developer A or the rename done by himself.
After developer B has manually resolved the conflict, the tree conflict has to be marked as resolved with the button in the conflict editor dialog.