Penggabungan: Hg / Git vs. SVN

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.

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

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.

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.

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.

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

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.