Mengapa saya mendapatkan konflik pohon di Subversion?


353

Saya memiliki cabang fitur dari bagasi saya dan menggabungkan perubahan dari bagasi saya ke cabang saya secara berkala dan semuanya bekerja dengan baik. Hari ini saya pergi untuk menggabungkan cabang kembali ke bagasi dan salah satu file yang ditambahkan ke bagasi saya setelah penciptaan cabang saya ditandai sebagai "konflik pohon". Apakah ada cara untuk menghindari ini di masa depan?

Saya tidak berpikir ini ditandai dengan benar.


Bisakah Anda memberikan resep untuk mereproduksi masalah ini mulai dari repositori kosong?
Wim Coenen

Saya akan mencoba dan mencari waktu hari ini untuk membuat repo baru dan menguji ini dan mendapatkan hasil yang sama dan mengirim kembali. Terima kasih.
Greg

Jawaban:


399

Saya menemukan solusi membaca tautan yang diberikan Gary (dan saya sarankan untuk mengikuti cara ini).

Meringkas untuk menyelesaikan konflik pohon melakukan direktori kerja Anda dengan klien SVN 1.6.x Anda dapat menggunakan:

svn resolve --accept working -R .

di mana .direktori dalam konflik.

PERINGATAN : "Komit direktori kerja Anda" berarti bahwa struktur kotak pasir Anda akan menjadi yang Anda komit, jadi jika, misalnya, Anda menghapus beberapa file dari kotak pasir Anda, mereka akan dihapus dari repositori juga. Ini hanya berlaku untuk direktori yang konflik.

Dengan cara ini, kami menyarankan SVN untuk menyelesaikan konflik ( --resolve), menerima copy pekerjaan di dalam kotak pasir Anda ( --accept working), secara rekursif ( -R), mulai dari direktori saat ini ( .).

Di TortoiseSVN, memilih "Terselesaikan" pada klik kanan, sebenarnya menyelesaikan masalah ini.


32
Dengan cara ini Anda menyarankan untuk svn menyelesaikan konflik (--resolve), menerima copy pekerjaan di dalam kotak pasir Anda (--accept working), secara rekursif (-R), mulai dari direktori saat ini (.) HTH
gicappa

22
di TortoiseSvn, memilih "Terselesaikan" pada klik kanan, sebenarnya menyelesaikan masalah ini.
understack

40
Apakah ini tidak secara membabi buta hanya menerima copy pekerjaan? Maksud saya, saya merasa tidak tahu di mana ada masalah dengan konflik ini, tetapi jika saya hanya menyelesaikan dan menerima pekerjaan, bukankah itu hanya akan menghapus pekerjaan orang lain?
Parris

10
Salah satu penyebab terjadinya ini bisa jadi Anda svn rm'ddirektori yang Anda pikir tidak lagi diperlukan, tetapi orang lain menambahkan file baru yang diperlukan. Ketika Anda memperbarui copy pekerjaan Anda, Anda harus mendapatkan konflik pohon. Jika Anda hanya menerima solusi Anda secara membabi buta (menghapus direktori) maka Anda akan menghapus file orang itu. Tidak ada tombol ajaib "lakukan hal yang benar". Anda harus memahami apa yang sedang Anda lakukan, mengapa itu bertentangan dengan versi terbaru, dan bagaimana cara mengatasinya dengan benar.
bambams

5
@TWiStErRob, saya berpendapat gejala ini menunjukkan masalah yang melekat pada SVN sebagai alat kontrol versi. Secara pribadi, cara untuk 'menghindari' masalah ini di masa depan adalah dengan menggunakannya git. Karena itu kemungkinan besar bukan pilihan praktis bagi penanya, maka berurusan dengan situasi seperti yang dijabarkan oleh jawaban ini adalah pilihan terbaik.
Jess Telford

59

Subversion 1.6 menambahkan Pohon Konflik untuk meliput konflik di tingkat direktori. Contoh yang baik adalah ketika Anda secara lokal menghapus file maka pembaruan mencoba membawa perubahan teks pada file itu. Lain adalah ketika Anda memiliki subversi Ubah nama file yang Anda edit karena itu adalah tindakan Tambah / Hapus.

Blog Subversion CollabNet memiliki artikel hebat tentang Konflik Pohon .


9
Tak satu pun dari contoh ini yang Anda berikan berkaitan dengan situasi saya. Mungkin uraian saya tidak jelas?
Greg

33

Dalam pengalaman saya, SVN menciptakan konflik pohon SETIAP AKU menghapus folder. Tampaknya tidak ada alasan.

Saya satu-satunya yang mengerjakan kode saya -> hapus direktori -> komit -> konflik!

Saya tidak sabar untuk beralih ke Git .

Saya harus mengklarifikasi - Saya menggunakan Subclipse . Mungkin itu masalahnya! Sekali lagi, saya tidak sabar untuk beralih ...


2
Masalah yang sama dari klien baris perintah SVN, jadi itu bukan Eclipse.
dolmen

3
Saya memiliki masalah yang sama dengan NetBeans dan SVN. Hapus direktori -> konflik.
Gruber

2
Masalah yang sama di sini ... sangat menyebalkan ... harus REVERT, perbarui, hapus dan komit ...
marcolopes

1
Saya menemukan trik hebat dengan IntelliJ Idea ketika saya mendapatkan konflik pohon. Saya menyimpan semua perubahan saya (ini sama dengan membuat tambalan dari perubahan saya dan kemudian mengembalikannya). Lalu saya melakukan pembaruan svn untuk mendapatkan perubahan terbaru dari Subversion. Setelah itu saya membatalkan perubahan saya (sama seperti menerapkan tambalan) dan biola!
ehrhardt

1
Saya tampaknya memiliki masalah yang sama menggunakan svn client 1.7.9 di Ubuntu 12.04.4 LTS terhadap repo Assembla.
siliconrockstar

28

Saya tidak tahu apakah ini terjadi pada Anda, tetapi kadang-kadang saya memilih direktori yang salah untuk digabung dan saya mendapatkan kesalahan ini meskipun semua file tampak benar-benar baik-baik saja.

Contoh:

Gabungkan / svn / Proyek / cabang / beberapa cabang / Sumber ke / svn / Proyek / trunk ---> Konflik pohon

Gabungkan / svn / Proyek / cabang / beberapa cabang ke / svn / Proyek / trunk ---> OK

Ini mungkin kesalahan yang bodoh, tetapi itu tidak selalu jelas karena Anda pikir itu sesuatu yang lebih rumit.


17

Apa yang terjadi di sini adalah sebagai berikut: Anda membuat file baru di bagasi Anda, kemudian Anda menggabungkannya ke cabang Anda. Dalam gabungan, file ini juga akan dibuat di cabang Anda.

Ketika Anda menggabungkan cabang Anda kembali ke bagasi, SVN mencoba melakukan hal yang sama lagi: Ia melihat bahwa file dibuat di cabang Anda, dan mencoba membuatnya di bagasi Anda di komit gabungan, tetapi sudah ada! Ini menciptakan konflik pohon.

Cara untuk menghindari ini, adalah dengan melakukan penggabungan khusus, reintegrasi . Anda dapat mencapai ini dengan --reintegratesaklar.

Anda dapat membaca tentang ini di dokumentasi: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Saat menggabungkan cabang Anda kembali ke trunk, matematika yang mendasarinya sangat berbeda. Cabang fitur Anda sekarang merupakan mishmash dari kedua perubahan batang yang digandakan dan perubahan cabang pribadi, sehingga tidak ada rentang revisi yang berdekatan dan mudah untuk disalin. Dengan menentukan opsi --reintegrate, Anda meminta Subversion untuk dengan hati-hati mereplikasi hanya perubahan yang unik untuk cabang Anda. (Dan sebenarnya, ia melakukan ini dengan membandingkan pohon trunk terbaru dengan pohon cabang terbaru: perbedaan yang dihasilkan adalah persis perubahan cabang Anda!)

Setelah mengintegrasikan kembali cabang, sangat disarankan untuk menghapusnya, jika tidak, Anda akan terus mendapatkan treeconflicts setiap kali Anda bergabung ke arah lain: dari batang ke cabang Anda. (Untuk alasan yang persis sama seperti yang dijelaskan sebelumnya.)

Ada cara untuk mengatasi hal ini, tetapi saya tidak pernah mencobanya. Anda dapat membacanya di posting ini: Reintegrasi cabang subversi di v1.6


1
Turun karena --reintegratepilihan telah ditinggalkan dalam Subversion 1.8. Dimulai dengan SVN 1.8 penggabungan semacam itu otomatis!
bahrep

8
Terpilih karena banyak orang masih menggunakan subversi <1.8
juacala

Saya pikir menambahkan informasi versi SVN ke jawabannya akan berurutan.
Peter Mortensen

1
1.8 di sini dan itu tidak akan berfungsi tanpa solusi ini.
Musim dingin

Terpilih karena ini menjawab pertanyaan mengapa ini terjadi.
Joshua Breeden

7

Ini dapat disebabkan oleh tidak menggunakan klien versi yang sama di seluruh.

Menggunakan klien versi 1.5 dan klien versi 1.6 menuju repositori yang sama dapat menciptakan masalah semacam ini. (Aku hanya digigit sendiri.)


4

Jika Anda menemukan konflik pohon yang tidak masuk akal karena Anda tidak mengedit / menghapus / mendekati file, ada juga kemungkinan besar bahwa ada kesalahan dalam perintah penggabungan.

Apa yang bisa terjadi adalah Anda sebelumnya sudah menggabungkan banyak perubahan yang Anda sertakan dalam penggabungan saat ini. Misalnya, di trunk seseorang mengedit file, dan kemudian mengganti namanya. Jika dalam gabungan pertama Anda menyertakan sunting, dan kemudian dalam gabungan kedua sertakan sunting dan ganti nama (pada dasarnya menghapus), itu juga akan memberi Anda konflik pohon. Alasan untuk ini adalah bahwa edit yang sebelumnya digabungkan kemudian muncul sebagai milik Anda, dan karenanya penghapusan tidak akan dilakukan secara otomatis.

Ini bisa terjadi pada 1,4 repositori setidaknya, saya tidak yakin apakah mergetracking yang diperkenalkan pada 1.5 membantu di sini.


2

Hingga hari ini, setidaknya sejak 3 bulan yang lalu, saya secara teratur menemui ratusan konflik pohon ketika mencoba untuk menggabungkan cabang kembali ke batang (menggunakan TortoiseSVN 1.11 ). Apakah rebased atau tidak, BTW. Saya telah menggunakan TortoiseSVN sejak v1, kembali pada tahun 2004, dan saya biasa mengintegrasikan kembali cabang sepanjang waktu. Pasti ada sesuatu yang terjadi baru-baru ini?

Jadi hari ini saya menjalankan eksperimen sederhana ini, dan saya menemukan apa yang menciptakan konflik gila ini:

  1. Saya memotong bagasi @ 393;
  2. Saya memodifikasi puluhan file secara acak, serta membuat yang baru;
  3. Saya berkomitmen. Sekarang @ 395 (seorang rekan membayar 394 untuk melakukan barang-barangnya sendiri).
  4. Kemudian saya mencoba mengintegrasikan kembali cabang ke bagasi, hanya tes; mengikuti rekomendasi TortoiseSVN di panduan: "untuk menggabungkan semua revisi (mengintegrasikan kembali), biarkan kotak itu kosong". Untuk mencapai ini, saya mengklik kanan ke folder trunk, dan memilih "TortoiseSVN> Gabung, dari / path / ke / cabang", dan saya meninggalkan rentang putaran kosong , seperti yang disarankan pada dialog.

Diskusi: (lihat lampiran)

semua revisi ... apa? Sedikit yang saya tahu bahwa klien pasti merujuk pada " semua revisi target! (Trunk)", seperti, dalam proses reintegrasi cabang itu, saya melihat menyebutkan "Menggabungkan revisi 1-KEPALA"! OH TUHAN. Iblis yang malang, Anda jatuh ke kematian Anda di sini. Cabang itu lahir @ 393, tidak bisakah Anda membaca akta kelahirannya, demi Tuhan?inilah mengapa begitu banyak konflik terjadi: SVN-cli melakukan kebodohan dari revisi 1

Resolusi:

  1. Berlawanan dengan apa yang disarankan oleh wiz, tentukan rentang, yang mencakup SEMUA revisi ... kehidupan cabang! oleh karena itu, 394-KEPALA ;
  2. sekarang jalankan tes gabungan itu lagi, dan dapatkan cerutu. ( lihat lampiran kedua).

Moral: Saya tidak dapat memahami mengapa mereka masih belum memperbaiki bug itu, karena bug itu salah, saya minta maaf. Saya harus meluangkan waktu untuk melaporkan ini dengan mereka.


1

Saya menemukan masalah ini hari ini juga, meskipun masalah khusus saya mungkin tidak terkait dengan masalah Anda. Setelah memeriksa daftar file, saya menyadari apa yang telah saya lakukan - saya sementara menggunakan file dalam satu rakitan dari rakitan lain. Saya telah membuat banyak perubahan dan tidak ingin menjadi yatim sejarah SVN, jadi di cabang saya, saya telah memindahkan file dari folder majelis lain. Ini tidak dilacak oleh SVN, jadi sepertinya file tersebut dihapus dan kemudian ditambahkan kembali. Ini akhirnya menyebabkan konflik pohon.

Saya menyelesaikan masalah dengan memindahkan file kembali, melakukan, dan kemudian menggabungkan cabang saya. Kemudian saya memindahkan file itu kembali sesudahnya. :) Sepertinya ini akan berhasil.


1

Saya punya masalah serupa. Satu-satunya hal yang benar-benar berfungsi untuk saya adalah menghapus subdirektori yang konflik dengan:

svn delete --force ./SUB_DIR_NAME

Kemudian salin lagi dari direktori root lain di copy pekerjaan yang memilikinya:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Lalu lakukan

svn cleanup

dan

svn add *

Anda mungkin mendapatkan peringatan dengan yang terakhir, tetapi abaikan saja dan akhirnya

svn ci .

0

Saya memiliki masalah yang sama, dan menyelesaikannya dengan melakukan penggabungan ulang menggunakan instruksi ini . Pada dasarnya, ini menggunakan "2-URL penggabungan" SVN untuk memperbarui trunkke keadaan cabang Anda saat ini, tanpa terlalu peduli tentang sejarah dan konflik pohon. Menyelamatkan saya dari memperbaiki secara manual 114 pohon konflik.

Saya tidak yakin apakah itu melestarikan sejarah seperti yang diinginkan, tetapi itu layak untuk saya.


5
Sejarah adalah mengapa kita menggunakan VCS ... atau apakah saya melewatkan sesuatu?
TWiStErRob

0

Skenario yang terkadang saya temui:

Asumsikan Anda memiliki bagasi, dari mana Anda membuat cabang rilis. Setelah beberapa perubahan pada trunk (khususnya membuat direktori "some-dir"), Anda membuat cabang fitur / fix yang kemudian Anda inginkan juga bergabung ke dalam cabang rilis (karena perubahannya cukup kecil dan fitur / perbaikan penting untuk rilis) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Jika Anda kemudian mencoba untuk menggabungkan cabang fitur / perbaiki langsung ke cabang rilis Anda akan mendapatkan konflik pohon (meskipun direktori bahkan tidak ada di cabang fitur / perbaiki):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Jadi, Anda perlu secara eksplisit menggabungkan komit yang dilakukan pada trunk sebelum membuat cabang fitur / fix yang membuat direktori "some-dir" sebelum menggabungkan cabang fitur / perbaiki.

Saya sering lupa bahwa itu tidak perlu di git.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.