Terkadang, anda akan mendapat konflik ketika anda memperbarukan/menggabungkan file file anda dari repositori atau ketika anda mengubah copy pekerjaan anda ke URL yang berbeda. Ada dua macam konflik:
File konflik terjadi apabila dua (atau lebih) pengembang telah mengubah beberapa baris yang sama dari sebuah file
Susunan konflik terjadi ketika seorang pengembang telah memindahkan/mengubah nama/menghapus sebuah file atau folder, dimana pengembang lain juga telah memindahkan/mengubah nama/menghapus atau baru mengubahnya.
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. The conflicting area in a text file 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.
You can either launch an external merge tool / conflict editor with → or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the string <<<<<<<.
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 property conflict occurs when two or more developers have changed the same property. As with file content, resolving the conflict can only be done by the developers.
If one of the changes must override the other then choose the option to Resolve using local property or Resolve using remote property. If the changes must be merged then select Manually edit property, sort out what the property value should be and mark as resolved.
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 bisa membantu untuk mencari tempat yang benar untuk menggabungkan perubahan perubahan, tetapi pekerjaan tambahan mungkin diperlukan untung menyelesaikan konflik. Ingat, setelah pembaruan (an update), dasar kerjanya akan selalu mengandung revisi untuk setiap hal seperti didalam repositori di saat pembaruan. Jika anda mengembalikan perubahan setelah mempembarukan, itu akan mengembalikan ke keadaan repositori, bukan kembali ke keadaan disaat anda memulai mengubah lokal copy anda.
Developer A modifies Foo.c and commits it to the repository.
Pengembang B telah memindahkan Foo.c ke Bar.c secara bersamaan didalam duplikasi kerja dia, atau telah menghapus Foo.c atau induk foldernya.
Pembarukan dari pengembang B duplikasi kerja menghasilkan konflik pohon:
Foo.c telah dihapus dari duplikasi kerja, tetapi ditandai dengan konflik pohon.
Apabila konflik itu terjadi dari mengubah nama daripada menghapus, Bar.c ditandai dengan ditambahkan (added), tetapi tidak mengandung perubahan pengembang A.
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. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.
Developer A moves Foo.c to Bar.c and commits it to the repository.
Pengembang B mengubah Foo.c didalam duplikasi kerja dia.
Atau di dalam kasus memindahkan folder ...
Pengembang A memindahkan induk folder FooFolderke BarFolder dan me-komit kedalam repositori
Pengembang B mengubah Foo.c didalam duplikasi kerja dia.
Pembaruan dari duplikasi kerja pengembang B menghasilkan konflik. Untuk file konflik yang sederhana:
Bar.c ditambahkan ke dalam duplikat kerja sebagai file biasa.
Foo.c ditandai sebagai tambahan (dengan sejarah) dan mempunyai konflik pohon.
For a folder conflict:
BarFolder ditambahkan ke dalam duplikasi kerja sebagain folder biasa.
filename>FooFolder ditandai sebagain tambahan (dengan sejarah) dan mempunyari konflik pohon.Foo.c ditandai sebagain diubah (modified).
Sekarang Pengembang B memutuskan untuk menyetujui pengembang A reorganisasi dan menggabungkan perubahan dia ke dalam file yang bersangkutan di dalam struktur yang baru, atau hanya mengubah kembali perubahan pengembang A dan menyimpan file lokal.
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. Then use the button which shows the correct source file to resolve the conflict.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved 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.
Pembarukan dari pengembang B duplikasi kerja menghasilkan konflik pohon:
Bix.c ditandai sebagai tambahan dengan sejarah.
Bar.c ditambahi ke duplikasi kerja dengan 'normal' status.
Foo.c ditandai sebagai terhapus dan mempunyai konflik pohon.
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.
Setelah pengembang B menyelesaikan konflik secara manual, pohon konflik harus ditandai dengan selesai dengan tombol yang ada di konflik 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 sudah ada di dalam duplikasi kerja dengan 'normal' status.
Foo.c ditandai sebagain hilang (missing) dengan konflik pohon.
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.
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 ditandai dengan tambahan (added).
Foo.c ditandai sebagai terubah dengan konflik pohon.
Sekarang Pengembang B memutuskan untuk menyetujui pengembang A reorganisasi dan menggabungkan perubahan dia ke dalam file yang bersangkutan di dalam struktur yang baru, atau hanya mengubah kembali perubahan pengembang A dan menyimpan file lokal.
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.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved 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 ditandai sebagai status normal (tidak diubah, unmodified).
Bar.c ditandai sebagai tambahan dengan sejarah.
Foo.c ditandai dengan hilang dan mempunyai konflik pohon.
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.
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.
Setelah pengembang B menyelesaikan konflik secara manual, pohon konflik harus ditandai dengan selesai dengan tombol yang ada di konflik editor dialog.
There are other cases which are labelled as tree conflicts simply because the conflict involves a folder rather than a file. For example if you add a folder with the same name to both trunk and branch and then try to merge you will get a tree conflict. If you want to keep the folder from the merge target, just mark the conflict as resolved. If you want to use the one in the merge source then you need to SVN delete the one in the target first and run the merge again. If you need anything more complicated then you have to resolve manually.