Penggabungan: Hg / Git vs. SVN


144

Saya sering membaca bahwa Hg (dan Git dan ...) lebih baik dalam menggabungkan daripada SVN tetapi saya belum pernah melihat contoh praktis di mana Hg / Git dapat menggabungkan sesuatu di mana SVN gagal (atau di mana SVN membutuhkan intervensi manual). Bisakah Anda memposting beberapa langkah demi langkah daftar cabang / memodifikasi / melakukan / ...- operasi yang menunjukkan di mana SVN akan gagal sementara Hg / Git dengan senang hati melanjutkan? Kasus praktis, bukan sangat luar biasa, mohon ...

Beberapa latar belakang: kami memiliki beberapa lusin pengembang yang mengerjakan proyek menggunakan SVN, dengan masing-masing proyek (atau kelompok proyek serupa) di repositori sendiri. Kami tahu cara menerapkan rilis dan fitur-cabang sehingga kami tidak mengalami masalah sangat sering (yaitu, kami sudah ada di sana, tetapi kami telah belajar untuk mengatasi masalah Joel tentang "satu programmer yang menyebabkan trauma bagi seluruh tim" atau "membutuhkan enam pengembang selama dua minggu untuk mengintegrasikan kembali cabang"). Kami memiliki cabang rilis yang sangat stabil dan hanya digunakan untuk menerapkan perbaikan bug. Kami memiliki batang yang harus cukup stabil untuk dapat membuat rilis dalam satu minggu. Dan kami memiliki cabang fitur yang dapat dikembangkan oleh pengembang tunggal atau grup pengembang. Ya, mereka dihapus setelah reintegrasi sehingga mereka tidak mengacaukan repositori. ;)

Jadi saya masih mencoba mencari keuntungan dari Hg / Git dibandingkan SVN. Saya ingin mendapatkan pengalaman langsung, tetapi belum ada proyek yang lebih besar yang bisa kami pindah ke Hg / Git, jadi saya terjebak dengan bermain dengan proyek buatan kecil yang hanya berisi beberapa file buatan. Dan saya sedang mencari beberapa kasus di mana Anda dapat merasakan kekuatan Hg / Git yang mengesankan, karena sejauh ini saya sering membaca tentang mereka tetapi gagal menemukannya sendiri.


2
Saya pikir Anda harus memperhatikan duplikat yang tepat: stackoverflow.com/questions/43995/… stackoverflow.com/questions/459891/…
P Shved

11
Saya sudah membaca yang pertama, yang lain baru. Tapi mereka sudah berusia 1-2 tahun dan tampaknya sebagian besar tentang masalah pra-svn-1.5 (di mana svn belum memiliki pelacakan gabungan).
stmax

2
Hanya sebuah komentar bahwa Anda juga dapat menggabungkan Bazaar dengan git / hg sebagai DVCS lain yang akan menangani masalah di bawah ini dengan benar. Dan karena Anda menyebutkan mencoba untuk menemukan keuntungan: satu keuntungan logistik sederhana dari git / hg / bzr adalah bahwa cabang tidak global seperti halnya dengan svn. Anda tidak harus melihat 67 cabang, ketika hanya pasangan yang berlaku untuk Anda. Semua orang melakukan pekerjaan mereka di cabang "pribadi" dan kemudian menggunakan kemampuan penggabungan yang sangat baik untuk bergabung kembali tanpa berkeringat apakah penggabungan tersebut akan bekerja di 99% kasus.
wadesworld

5
@wade: apakah Anda melihat cabang "pribadi" sebagai keuntungan di lingkungan perusahaan? Saya khawatir tentang cadangan. saya sering memiliki cabang fitur yang hidup selama 1-2 bulan sebelum reintegrasi ..
stmax

9
@stmax: Kekhawatiran yang valid. Namun, apa yang Anda temukan di banyak lingkungan perusahaan dengan subversi adalah bahwa orang-orang menunda untuk memeriksa hingga kode mereka sempurna, dan Anda memiliki eksposur yang sama di sana.
wadesworld

Jawaban:


91

Saya tidak menggunakan Subversion sendiri, tetapi dari catatan rilis untuk Subversion 1.5: Pelacakan gabungan (dasar) sepertinya ada perbedaan berikut dari cara kerja pelacakan gabungan dalam sistem kontrol versi DAG penuh seperti Git atau Mercurial.

  • Menggabungkan batang ke cabang berbeda dari menggabungkan cabang ke batang: untuk beberapa alasan penggabungan batang ke cabang membutuhkan --reintegrate opsi untuk svn merge.

    Dalam sistem kontrol versi terdistribusi seperti Git atau Mercurial tidak ada perbedaan teknis antara trunk dan cabang: semua cabang dibuat sama (mungkin ada perbedaan sosial ). Penggabungan kedua arah dilakukan dengan cara yang sama.

  • Anda perlu memberikan opsi baru -g( --use-merge-history) ke svn logdan svn blameuntuk menggabungkan pelacakan ke akun.

    Dalam Git dan Mercurial merge tracking secara otomatis diperhitungkan saat menampilkan histori (log) dan menyalahkan. Di Git Anda dapat meminta untuk mengikuti induk pertama saja dengan --first-parent(saya kira opsi serupa juga ada untuk Mercurial) untuk "membuang" menggabungkan info pelacakan di git log.

  • Dari apa yang saya pahami svn:mergeinfo, toko properti informasi per-lintasan tentang konflik (Subversion berbasis-ubah), sedangkan di Git dan Mercurial, ia hanya melakukan objek yang dapat memiliki lebih dari satu orangtua.

  • Subbagian "Masalah yang Diketahui" untuk pelacakan gabungan di Subversion menunjukkan bahwa gabungan berulang / siklik / reflektif mungkin tidak berfungsi dengan baik. Ini berarti bahwa dengan riwayat berikut, penggabungan kedua mungkin tidak melakukan hal yang benar ('A' dapat berupa batang atau cabang, dan 'B' masing-masing dapat berupa cabang atau batang):

    * --- * --- x --- * --- y --- * --- * --- * --- M2 <- A
             \ \ /
              - * ---- M1 --- * --- * --- / <- B
    

    Dalam kasus ASCII-art di atas rusak: Cabang 'B' dibuat (bercabang) dari cabang 'A' pada revisi 'x', kemudian cabang 'A' digabung pada revisi 'y' menjadi cabang 'B' sebagai cabang menggabungkan 'M1', dan akhirnya cabang 'B' digabung menjadi cabang 'A' sebagai gabungan 'M2'.

    * --- * --- x --- * ----- M1 - * --- * --- M2 <- A
             \ / / 
              \ - * --- y --- * --- * --- / <- B
    

    Dalam kasus ASCII-art di atas rusak: Cabang 'B' dibuat (bercabang) dari cabang 'A' pada revisi 'x', itu digabung menjadi cabang 'A' di 'y' sebagai 'M1', dan kemudian bergabung kembali ke cabang 'A' sebagai 'M2'.

  • Subversi mungkin tidak mendukung kasus penggabungan silang tingkat lanjut .

    * --- b ----- B1 - M1 - * --- M3
         \ \ / /
          \ X /
           \ / \ /
            \ - B2 - M2 - *
    

    Git menangani situasi ini dengan baik dalam praktiknya menggunakan strategi gabungan "rekursif". Saya tidak yakin tentang Mercurial.

  • Dalam "Masalah yang Diketahui" ada peringatan bahwa penggabungan pelacakan mungkin tidak berfungsi dengan penggantian nama file, misalnya ketika satu sisi mengubah nama file (dan mungkin mengubahnya), dan sisi kedua memodifikasi file tanpa mengganti nama (dengan nama lama).

    Baik Git dan Mercurial menangani kasus seperti itu dalam praktiknya: Git menggunakan deteksi nama , Mercurial menggunakan pelacakan nama .

HTH


entah bagaimana (kesalahan dalam Markdown parser?) bagian setelah <pre>...</pre>blok tidak di-indentasi sebagaimana mestinya ...
Jakub Narębski

1
+1 untuk banyak contoh terperinci. Saya belum mengerti mengapa contoh pada ascii-art pertama mungkin menyebabkan masalah. sepertinya cara standar untuk merawat cabang fitur: menganggap A adalah trunk, B adalah cabang fitur. Anda menggabungkan mingguan dari A ke B dan ketika Anda selesai dengan fitur Anda menggabungkan semuanya dari B ke A dan kemudian menghapus B. yang selalu berhasil untuk saya. Apakah saya salah mengerti diagram?
stmax

1
Perhatikan bahwa saya tidak tahu (saya belum memeriksa) bahwa contoh yang diberikan di atas benar - benar memberikan masalah dalam Subversion . Mengganti nama dan menggabungkan silang adalah masalah nyata di SVN, saya pikir.
Jakub Narębski

2
reintegrate merge adalah opsi khusus untuk membantu Anda dalam kasus yang paling umum ketika menggabungkan - tidak ada perbedaan teknis antara cabang dan trunk di svn. Saya cenderung tidak pernah menggunakannya, dan tetap dengan opsi penggabungan standar. Namun, satu-satunya masalah dengan svn merge adalah bahwa ia memperlakukan pemindahan / penggantian nama sebagai tambahan delete +.
gbjbaanb

--reintegratesudah ditinggalkan.
naught101

120

Saya juga telah mencari kasus di mana, katakanlah, Subversion gagal menggabungkan cabang dan Mercurial (dan Git, Bazaar, ...) melakukan hal yang benar.

Buku SVN menjelaskan bagaimana file yang diganti nama digabungkan secara tidak benar . Ini berlaku untuk Subversion 1.5 , 1.6 , 1.7 , dan 1.8 ! Saya telah mencoba membuat ulang situasi di bawah ini:

cd / tmp
rm - rf svn - repo svn - checkout
svnadmin membuat svn - repo
svn checkout file : /// tmp / svn - repo svn - checkout
cd svn - checkout
cabang batang mkdir
gema 'Selamat tinggal, Dunia!' > trunk / halo . txt
svn tambahkan cabang trunk
svn commit - m 'Impor awal.' 
svn salin '^ / trunk' '^ / branch / rename' - m 'Buat cabang.' 
svn beralih '^ / trunk' . 
gema 'Halo, Dunia!' > halo . txt    
svn commit - m 'Perbarui di trunk.' 
svn beralih '^ / cabang / ganti nama' . 
svn ganti nama halo . txt halo . id . txt
svn commit - m 'Ganti nama di cabang.' 
svn beralih '^ / trunk' . 
svn merge - reintegrate '^ / branch / rename' 

Menurut buku itu, penggabungan harus selesai dengan bersih, tetapi dengan data yang salah dalam file yang diubah namanya karena pembaruan pada trunkdilupakan. Sebaliknya saya mendapatkan konflik pohon (ini dengan Subversion 1.6.17, versi terbaru di Debian pada saat penulisan):

--- Menggabungkan perbedaan antara URL repositori ke '.':
A hello.en.txt
   C hello.txt
Ringkasan konflik:
  Konflik pohon: 1

Seharusnya tidak ada konflik sama sekali - pembaruan harus digabung dengan nama file yang baru. Sementara Subversion gagal, Mercurial menangani ini dengan benar:

rm -rf /tmp/hg-repo
hg init /tmp/hg-repo
cd /tmp/hg-repo
echo 'Goodbye, World!' > hello.txt
hg add hello.txt
hg commit -m 'Initial import.'
echo 'Hello, World!' > hello.txt
hg commit -m 'Update.'
hg update 0
hg rename hello.txt hello.en.txt
hg commit -m 'Rename.'
hg merge

Sebelum penggabungan, repositori terlihat seperti ini (dari hg glog):

@ changeset: 2: 6502899164cc
| tag: tip
| induk: 0: d08bcebadd9e
| pengguna: Martin Geisler
| tanggal: Kamis 01 Apr 12:29:19 2010 +0200
| ringkasan: Ganti nama.
|
| o changeset: 1: 9d06fa155634
| / pengguna: Martin Geisler 
| tanggal: Kamis 01 Apr 12:29:18 2010 +200
| ringkasan: Pembaruan.
|
o changeset: 0: d08bcebadd9e
   pengguna: Martin Geisler 
   tanggal: Kamis 01 Apr 12:29:18 2010 +200
   ringkasan: Impor awal.

Output dari penggabungan adalah:

menggabungkan hello.en.txt dan hello.txt ke hello.en.txt
0 file diperbarui, 1 file digabung, 0 file dihapus, 0 file tidak terselesaikan
(cabang bergabung, jangan lupa untuk melakukan)

Dengan kata lain: Mercurial mengambil perubahan dari revisi 1 dan menggabungkannya ke nama file baru dari revisi 2 ( hello.en.txt). Penanganan kasus ini tentu saja penting untuk mendukung refactoring dan refactoring adalah persis jenis hal yang Anda ingin lakukan pada cabang.


+1 sebagai contoh terperinci, seseorang dapat menyentuh keyboard dan melihat sendiri apa yang terjadi. Sebagai nour Mercurial, saya bertanya-tanya apakah versi hg dari contoh ini diikuti dengan cara yang jelas, baris demi baris?
DarenW

4
@ DarenW: Saya telah menambahkan perintah Mercurial yang sesuai, saya harap ini membuat semuanya menjadi lebih jelas!
Martin Geisler

17

Tanpa berbicara tentang keuntungan biasa (komit offline, proses publikasi , ...) di sini adalah contoh "gabungan" yang saya suka:

Skenario utama yang terus saya lihat adalah cabang di mana ... dua tugas yang tidak terkait sebenarnya dikembangkan
(dimulai dari satu fitur, tetapi mengarah pada pengembangan fitur lain ini.
Atau mulai dari tambalan, tetapi mengarah ke pengembangan fitur lain).

Bagaimana Anda menggabungkan hanya satu dari dua fitur di cabang utama?
Atau Bagaimana Anda mengisolasi dua fitur di cabang mereka sendiri?

Anda dapat mencoba untuk menghasilkan beberapa jenis tambalan, masalah dengan itu adalah Anda tidak yakin lagi tentang dependensi fungsional yang mungkin ada antara:

  • komit (atau revisi untuk SVN) yang digunakan di tambalan Anda
  • yang lain tidak melakukan bagian dari patch

Git (dan Mercurial juga saya kira) mengusulkan opsi rebase --onto untuk rebase (reset root dari cabang) bagian dari cabang:

Dari pos Jefromi

- x - x - x (v2) - x - x - x (v2.1)
           \
            x - x - x (v2-only) - x - x - x (wss)

Anda dapat menguraikan situasi ini di mana Anda memiliki tambalan untuk v2 serta fitur wss baru ke:

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - x - x (v2-only)
           \
             x - x - x (wss)

, memungkinkan Anda untuk:

  • uji setiap cabang secara terpisah untuk memeriksa apakah semuanya dikompilasi / berfungsi sebagaimana dimaksud
  • gabungkan hanya apa yang ingin Anda mainkan.

Fitur lain yang saya sukai (yang memengaruhi penggabungan) adalah kemampuan untuk menekan komit (di cabang yang belum didorong ke repo lain) untuk menyajikan:

  • sejarah yang lebih bersih
  • komit yang lebih koheren (daripada commit1 untuk function1, commit2 untuk function2, commit3 lagi untuk function1 ...)

Itu memastikan penggabungan yang jauh lebih mudah, dengan lebih sedikit konflik.


svn tidak memiliki komitmen offline? rofl? bagaimana bisa ada orang yang bahkan mempertimbangkan untuk menggunakannya jika memang begitu?
o0 '.

@ Lohoris Ketika SVN keluar, tidak ada DVCS open-source yang banyak digunakan; pada titik ini, saya pikir sebagian besar inersia bahwa orang masih menggunakannya.
Max Nanasy

@ MaxNanasy jenis inersia yang sangat buruk ... masih, memilihnya sekarang akan sangat bodoh.
o0 '.

@Lohoris Online (lebih tepatnya, terpusat) komit bukan masalah besar dalam tim kecil di mana repositori dapat dengan mudah berada di server lokal bersama. DVCSes sebagian besar diciptakan untuk tim-tim besar, yang tersebar secara geografis (baik git dan lincah dimaksudkan untuk mengelola kode kernel Linux) dan proyek-proyek open source (karenanya popularitas GitHub). Inersia juga dapat dilihat sebagai evaluasi risiko vs manfaat dari mengubah alat yang menjadi pusat alur kerja tim.
IMSoP

1
@ Lohoris Saya pikir Anda salah mengerti maksud saya tentang DB, firewall, dll: ada sedikit gunanya saya dapat melakukan pada mesin rumah saya jika saya tidak dapat benar-benar menjalankan kode itu terlebih dahulu. Saya bisa bekerja buta, tetapi fakta bahwa saya tidak bisa melakukan sesuatu di suatu tempat tidak akan menjadi hal utama yang membuat saya marah.
IMSoP

8

Kami baru-baru ini bermigrasi dari SVN ke GIT, dan menghadapi ketidakpastian yang sama. Ada banyak bukti anekdotal bahwa GIT lebih baik, tetapi sulit untuk menemukan contoh apa pun.

Saya dapat memberitahu Anda, bahwa GIT adalah BANYAK LEBIH BAIK di penggabungan dari SVN. Ini jelas anekdotal, tetapi ada tabel untuk diikuti.

Berikut adalah beberapa hal yang kami temukan:

  • SVN digunakan untuk memunculkan banyak konflik pohon dalam situasi di mana sepertinya tidak seharusnya. Kami tidak pernah sampai ke dasar ini tetapi itu tidak terjadi di GIT.
  • Meskipun lebih baik, GIT secara signifikan lebih rumit. Luangkan waktu untuk pelatihan.
  • Kami terbiasa dengan Tortoise SVN, yang kami sukai. Tortoise GIT tidak sebaik dan ini bisa membuat Anda pergi. Namun saya sekarang menggunakan baris perintah GIT yang saya lebih suka ke Tortoise SVN atau salah satu dari GIT GUI.

Ketika kami mengevaluasi GIT, kami menjalankan tes berikut. Ini menunjukkan GIT sebagai pemenang dalam hal penggabungan, tetapi tidak sebanyak itu. Dalam praktiknya perbedaannya jauh lebih besar, tapi saya kira kita belum berhasil meniru situasi yang ditangani SVN dengan buruk.

Evaluasi Penggabungan GIT vs SVN


5

Yang lain telah membahas aspek yang lebih teoretis dari ini. Mungkin saya bisa memberikan perspektif yang lebih praktis.

Saat ini saya bekerja untuk perusahaan yang menggunakan SVN dalam model pengembangan "cabang fitur". Itu adalah:

  • Tidak ada pekerjaan yang bisa dilakukan di bagasi
  • Setiap pengembang dapat membuat cabang sendiri
  • Cabang harus berlangsung selama durasi tugas yang dilakukan
  • Setiap tugas harus memiliki cabang sendiri
  • Penggabungan kembali ke trunk perlu diotorisasi (biasanya melalui bugzilla)
  • Pada saat dibutuhkan tingkat kontrol yang tinggi, penggabungan dapat dilakukan oleh gatekeeper

Secara umum, ini berfungsi. SVN dapat digunakan untuk aliran seperti ini, tetapi itu tidak sempurna. Ada beberapa aspek SVN yang menghalangi dan membentuk perilaku manusia. Itu memberinya beberapa aspek negatif.

  • Kami memiliki beberapa masalah dengan orang yang bercabang dari poin lebih rendah dari ^/trunk . Sampah ini menggabungkan catatan informasi di seluruh pohon, dan akhirnya memecah pelacakan gabungan. Konflik palsu mulai muncul, dan kebingungan berkuasa.
  • Mengambil perubahan dari batang ke cabang relatif lurus ke depan. svn mergelakukan apa yang kamu inginkan. Menggabungkan perubahan Anda membutuhkan (kami diberitahu) --reintegratepada perintah penggabungan. Saya tidak pernah benar-benar memahami saklar ini, tetapi itu berarti bahwa cabang tidak dapat digabungkan menjadi bagasi lagi. Ini berarti cabang yang mati dan Anda harus membuat yang baru untuk melanjutkan pekerjaan. (Lihat Catatan)
  • Seluruh bisnis melakukan operasi di server melalui URL ketika membuat dan menghapus cabang benar-benar membingungkan dan membuat orang takut. Jadi mereka menghindarinya.
  • Berpindah antar cabang mudah salah, menyisakan sebagian pohon memandang cabang A, sementara meninggalkan bagian lain memandang cabang B. Jadi, orang lebih suka melakukan semua pekerjaan mereka di satu cabang.

Apa yang cenderung terjadi adalah bahwa seorang insinyur membuat cabang pada hari 1. Dia memulai pekerjaannya dan melupakannya. Beberapa waktu kemudian seorang bos datang dan bertanya apakah dia bisa melepaskan pekerjaannya ke bagasi. Insinyur telah takut hari ini karena reintegrasi berarti:

  • Menggabungkan dahannya yang sudah berumur kembali ke bagasi dan menyelesaikan semua konflik, dan merilis kode yang tidak terkait yang seharusnya ada di cabang yang terpisah, tetapi tidak.
  • Menghapus cabangnya
  • Membuat cabang baru
  • Memindahkan copy pekerjaannya ke cabang baru

... dan karena insinyur melakukan ini sesedikit mungkin, mereka tidak dapat mengingat "mantra sihir" untuk melakukan setiap langkah. Sakelar dan URL salah terjadi, dan tiba-tiba berantakan dan mereka mendapatkan "pakar".

Akhirnya semuanya beres, dan orang-orang belajar bagaimana mengatasi kekurangannya, tetapi setiap pemula baru melewati masalah yang sama. Realitas akhirnya (yang bertentangan dengan apa yang saya jelaskan saat dia mulai) adalah:

  • Tidak ada pekerjaan yang dilakukan di bagasi
  • Setiap pengembang memiliki satu cabang utama
  • Cabang bertahan sampai pekerjaan perlu dirilis
  • Perbaikan bug yang dicentang cenderung mendapatkan cabang mereka sendiri
  • Penggabungan kembali ke bagasi dilakukan ketika diizinkan

...tapi...

  • Kadang-kadang pekerjaan membuatnya ke trunk ketika seharusnya tidak karena itu di cabang yang sama dengan yang lain.
  • Orang menghindari semua penggabungan (bahkan hal-hal yang mudah), sehingga orang sering bekerja dalam gelembung kecil mereka sendiri
  • Penggabungan besar cenderung terjadi, dan menyebabkan kekacauan dalam jumlah terbatas.

Syukurlah tim ini cukup kecil untuk mengatasinya, tetapi tidak akan berkembang. Masalahnya, semua ini bukan masalah dengan CVCS, tetapi lebih dari itu karena penggabungan tidak sepenting di DVCS mereka tidak selipis. "Gesekan gabungan" itu menyebabkan perilaku yang berarti bahwa model "Cabang Fitur" mulai rusak. Penggabungan yang baik harus menjadi fitur dari semua VCS, bukan hanya DVCS.


Menurut ini sekarang ada --record-onlysaklar yang dapat digunakan untuk menyelesaikan --reintegratemasalah, dan tampaknya v1.8 memilih kapan melakukan reintegrasi secara otomatis, dan itu tidak menyebabkan cabang mati setelah itu


Seperti yang saya pahami, opsi --reintegrate memberi tahu svn bahwa Anda telah menyelesaikan perubahan yang bertentangan ketika menggabungkan ke cabang fitur. Secara efektif, alih-alih memperlakukannya sebagai tambalan, itu menimpa seluruh file dengan versi cabang, setelah memeriksa dalam riwayat gabungan bahwa semua revisi trunk telah digabungkan ke dalam cabang.
IMSoP

@ IMSoP: mungkin, itu masuk akal. Itu yang tidak menjelaskan kepada saya mengapa itu perlu atau mengapa itu membuat penggabungan lebih lanjut dari cabang itu menjadi tidak mungkin. Tidak membantu bahwa opsi ini sebagian besar tidak berdokumen.
Paul S

Saya hanya pernah menggunakannya melalui TortoiseSVN, di mana itu selalu dijelaskan secara jelas di UI gabungan. Saya percaya SVN 1.8 secara otomatis memilih strategi yang tepat, dan tidak memerlukan opsi terpisah, tetapi saya tidak tahu apakah mereka telah memperbaiki algoritma penggabungan normal untuk menangani dengan benar cabang yang telah disetel ulang dengan cara ini.
IMSoP

3

Sebelum subversi 1.5 (jika saya tidak salah), subversi memiliki kelemahan yang signifikan karena tidak ingat menggabungkan sejarah.

Mari kita lihat kasus yang diuraikan oleh VonC:

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - A - x (v2-only)
           \
             x - B - x (wss)

Perhatikan revisi A dan B. Katakanlah Anda menggabungkan perubahan dari revisi A di cabang "wss" ke cabang "hanya-v2" di revisi B (untuk alasan apa pun), tetapi terus menggunakan kedua cabang. Jika Anda mencoba untuk menggabungkan dua cabang lagi menggunakan lincah, itu hanya akan menggabungkan perubahan setelah revisi A dan B. Dengan subversi, Anda harus menggabungkan semuanya, seolah-olah Anda tidak melakukan penggabungan sebelumnya.

Ini adalah contoh dari pengalaman saya sendiri, di mana penggabungan dari B ke A memakan waktu beberapa jam karena volume kode: itu akan sangat menyebalkan untuk dilalui lagi , yang akan menjadi kasus dengan subversi pra-1.5.

Lain, mungkin perbedaan yang lebih relevan dalam perilaku menggabungkan dari Hginit: Pendidikan ulang Subversion :

Bayangkan Anda dan saya sedang mengerjakan beberapa kode, dan kami bercabang kode itu, dan kami masing-masing pergi ke ruang kerja terpisah kami dan membuat banyak dan banyak perubahan pada kode itu secara terpisah, sehingga mereka telah menyimpang sedikit.

Ketika kita harus bergabung, Subversion mencoba melihat kedua revisi — kode saya yang dimodifikasi, dan kode Anda yang dimodifikasi — dan mencoba menerka bagaimana menghancurkan mereka bersama-sama dalam satu kekacauan besar yang tidak suci. Biasanya gagal, menghasilkan halaman dan halaman "menggabungkan konflik" yang tidak benar-benar konflik, hanya tempat di mana Subversion gagal mengetahui apa yang kami lakukan.

Sebaliknya, ketika kami bekerja secara terpisah di Mercurial, Mercurial sibuk menyimpan serangkaian perubahan. Jadi, ketika kita ingin menggabungkan kode kita bersama, Mercurial sebenarnya memiliki lebih banyak informasi: ia tahu apa yang kita masing-masing ubah dan dapat menerapkan kembali perubahan itu, daripada hanya melihat produk akhir dan mencoba menebak bagaimana memasukkannya bersama.

Singkatnya, cara Mercurial menganalisis perbedaan adalah (apakah?) Lebih unggul daripada subversi.


5
saya telah membaca hginit. Sayang sekali itu tidak menunjukkan contoh yang lebih praktis tentang di mana hg melakukan lebih baik daripada svn .. pada dasarnya itu memberitahu Anda untuk "percaya joel" bahwa hg hanya lebih baik. contoh sederhana yang dia tunjukkan mungkin bisa dilakukan dengan svn juga .. sebenarnya itu sebabnya saya membuka pertanyaan ini.
stmax

1
Berdasarkan bagaimana ini dikatakan, pertanyaan naif muncul di benak: bagaimana jika algoritma gabungan Mercurial dimasukkan ke dalam Subversion? Apakah svn akan sebagus hg? Tidak, karena keuntungan hg ada di organisasi level yang lebih tinggi, bukan teks-matematika level rendah yang menggabungkan garis dari file. Itulah ide baru yang harus kita ketahui oleh pengguna.
DarenW

@stmax: Saya bisa melihat apa yang Anda maksud. Namun, pendapat Joel atau siapa pun tidak terlalu penting: satu teknologi bisa lebih baik daripada yang lain (untuk satu set kasus penggunaan) atau tidak. @ DarenW dan @stmax: dari pengalaman pribadi saya, Hg menang karena operasi yang didistribusikan (saya tidak terhubung sepanjang waktu), kinerja (banyak operasi lokal), percabangan yang sangat intuitif ditenagai oleh algoritma penggabungan yang unggul, hg rollback, templated log output, hg glog, folder .hg tunggal ... Saya bisa melanjutkan, dan terus ... apa pun selain git dan bazaar terasa seperti straightjacket.
Tomislav Nakic-Alfirevic

Komentar hg yang dikutip tentang "perubahan" tampaknya agak tidak akurat bagi saya. SVN tahu betul perubahan apa yang sedang digabungnya (suatu perubahan pada dasarnya adalah perbedaan antara dua foto, dan sebaliknya, kan?), Dan dapat menerapkan masing-masing pada gilirannya jika diinginkan; tentu tidak perlu "menebak" apa pun. Jika itu membuat "satu kekacauan besar yang tidak suci" maka itu adalah masalah implementasi, bukan sesuatu yang mendasar bagi desain. Masalah utama yang sulit dipecahkan di atas desain arsitektur saat ini adalah pemindahan file / copy / rename.
IMSoP
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.