Kami Geeks Subversion dan kami ingin tahu manfaat Mercurial [ditutup]

22

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 5 tahun yang lalu .

Setelah membaca saya seorang geek Subversion, mengapa saya harus mempertimbangkan atau tidak mempertimbangkan Mercurial atau Git atau DVCS lainnya .

Saya memiliki pertanyaan tindak lanjut terkait. Saya membaca pertanyaan itu dan membaca tautan dan video yang direkomendasikan dan saya melihat manfaatnya tetapi saya tidak melihat keseluruhan mindshift yang dibicarakan orang.

Tim kami terdiri dari 8-10 pengembang yang bekerja pada satu basis kode besar yang terdiri dari 60 proyek. Kami menggunakan Subversion dan memiliki trunk utama. Ketika seorang pengembang memulai case Fogbugz baru mereka membuat cabang svn, melakukan pekerjaan pada cabang dan setelah selesai mereka bergabung kembali ke bagasi. Kadang-kadang mereka dapat tinggal di cabang untuk waktu yang lama dan menggabungkan batang ke cabang untuk mengambil perubahan.

Ketika saya melihat Linus berbicara tentang orang-orang yang membuat cabang dan tidak pernah melakukannya lagi, itu bukan kita sama sekali. Kami mungkin membuat 50-100 cabang seminggu tanpa masalah. Tantangan terbesar adalah penggabungan tetapi kami juga cukup bagus dalam hal itu. Saya cenderung bergabung dengan case fogbugz & checkin daripada seluruh akar cabang.

Kami tidak pernah bekerja dari jarak jauh dan kami tidak pernah membuat cabang dari cabang. Jika Anda satu-satunya yang bekerja di bagian basis kode tersebut maka penggabungan ke trunk berjalan dengan lancar. Jika orang lain telah memodifikasi bagian kode yang sama maka penggabungannya bisa berantakan dan Anda mungkin perlu melakukan beberapa operasi. Konflik adalah konflik, saya tidak melihat bagaimana sistem apa pun bisa memperbaikinya sebagian besar waktu kecuali jika cukup pintar untuk memahami kode.

Setelah membuat cabang, checkout berikut dari file 60k + membutuhkan waktu tetapi itu akan menjadi masalah dengan sistem kontrol sumber yang akan kami gunakan.

Apakah ada manfaat dari DVCS yang tidak kami lihat akan sangat membantu kami?

— Mat
sumber

Tampaknya seolah-olah Anda sudah menggunakan SVN sebagai DVCS (sehubungan dengan percabangan, lagi pula). Saya yakin Anda dapat melakukan hampir semua yang dapat dilakukan Mercurial dengan SVN (dan sebaliknya); pertanyaannya kemudian, mana yang lebih mudah digunakan dan lebih nyaman untuk skenario pengembangan khusus Anda? Saya pikir Anda harus mencoba Mercurial sebentar untuk melihat sendiri apakah itu layak atau tidak

— Cameron

Saya penggemar Mercurial dan jelas menawarkan superset fitur SVN, tetapi yang dikatakan fitur-fitur tambahan hanya benar-benar berguna untuk sebagian kecil proyek. Anda mungkin tidak membutuhkannya, itu tidak akan mengubah hidup Anda, tetapi Anda akan mendapatkan lebih banyak fitur dan tidak kehilangan apa pun, jadi mengapa tidak?

— jiggy

Sudahkah Anda memeriksa Hg Init ? Ini adalah tutorial Mercurial yang ditulis oleh Joel Spolsky. Ini dimulai dengan bab untuk pengguna Subversion, tetapi jika tidak Anda tidak tahu apa-apa tentang DVCS.

— Barry Brown

11

Untuk mengulangi pertanyaan Anda, "Jika kami berencana hanya menggunakan DVCS secara terpusat, manfaat apa yang dimilikinya?" Ketika Anda bertanya seperti itu, itu tidak benar. Satu cabang per tugas sangat umum di VCS. Jika Anda berpikir tentang hal itu, memiliki salinan kode sumber kerja di mesin pengembang yang berubah secara independen dari bagasi selama sehari adalah cabang, meskipun tidak ada yang menyebutnya begitu. Satu-satunya perbedaan antara itu dan alur kerja Anda adalah Anda memberikan cabang-cabang itu nama permanen di server pusat juga. Itu bukan jenis percabangan yang dibicarakan Linus dan yang lainnya.

Untuk memahami DVCS dibutuhkan perubahan mendasar dalam berpikir. Anda harus bertanya pada diri sendiri apa yang akan Anda lakukan dengan sebanyak cabang yang Anda inginkan yang dibagikan dengan siapa pun yang Anda inginkan, dan hanya mereka. Itu termasuk cabang yang hanya dilihat sendiri.

Kemungkinannya tidak terbatas. Untuk satu contoh saja, bagaimana dengan dua orang yang bekerja di sisi yang berlawanan dari sebuah antarmuka? Mereka perlu berbagi kode satu sama lain secara teratur, tetapi belum cukup stabil untuk dibagikan kepada semua orang. Mereka dapat membuat cabang untuk dibagikan di antara mereka sendiri, kemudian menggabungkannya kembali ke repositori pusat ketika sudah siap.

Kemampuan untuk melakukan komit lokal menengah layak dilakukan sendirian. Itu adalah sesuatu yang harus Anda alami sendiri.

Kecepatan yang didapat dari repo lokal Anda juga layak dilakukan sendirian. Ya, klon awal akan lambat pasti di setiap VCS untuk repo file 60k, tapi begitu Anda memilikinya, memeriksa cabang baru adalah urutan besarnya lebih cepat dengan DVCS.

— Karl Bielefeldt
sumber

2

+1! Juga, jika Anda mencoba secara terang-terangan dan menyeluruh, saya yakin Anda tidak ingin kembali.

— Pete

1

"Anda harus bertanya pada diri sendiri apa yang akan Anda lakukan dengan cabang sebanyak yang Anda inginkan yang dibagikan dengan siapa pun yang Anda inginkan, dan hanya mereka" ... "dua orang yang bekerja di sisi yang berlawanan dari sebuah antarmuka? Mereka perlu berbagi kode dengan masing-masing lainnya secara teratur, tetapi belum cukup stabil untuk dibagikan dengan semua orang. Mereka dapat membuat cabang untuk dibagikan di antara mereka sendiri, kemudian menggabungkannya kembali ke repositori pusat saat siap. " Kami memiliki semua itu sekarang dengan subversi.

— Matt

@ Mat, maka Anda beruntung karena bisnis Anda lebih merupakan pengecualian daripada aturan. Sebagian besar perusahaan memiliki aturan yang sangat ketat tentang membuat cabang pada sumber daya terbatas dari server pusat, sehingga orang-orang bahkan tidak berpikir untuk membuat mereka untuk alasan sementara.

— Karl Bielefeldt

3

Saya pikir jawaban ini tidak memiliki fakta bahwa poster asli sudah memaksa SVN untuk bekerja dengan cara yang jauh lebih dekat dengan alur kerja DVCS daripada yang dianggap layak oleh sebagian besar pengguna SVN. Intinya mereka sudah memiliki pola pikir DVCS sehingga tidak diperlukan perubahan mendasar dalam berpikir .

— Mark Booth

Poin bagus @ Mark. Pada tim sekecil itu, banyak konvensi normal untuk tim yang lebih besar keluar jendela. Saya masih berpikir itu layak untuk alasan kecepatan.

— Karl Bielefeldt

1

Untuk kasus khusus Anda, tidak ada manfaatnya beralih ke DVCS. Anda senang dengan sistem yang ada, itu melakukan semua yang Anda butuhkan, jadi mengapa beralih? SVN masih merupakan proyek Open Source aktif, dan memiliki integrasi yang lebih baik, lebih matang dengan semua IDE utama dan alat pengembangan daripada baik hg atau git. Mengingat ukuran tim Anda dan jumlah proyek, apakah Anda benar-benar ingin meluangkan waktu untuk mengonversi ke alat baru ketika yang ada bekerja dengan baik?

Jika Anda memiliki pengembang yang tidak dapat berfungsi tanpa DVCS, arahkan mereka ke gateway svn untuk hg atau git. Buatlah sangat jelas bagi mereka bahwa checkin mereka ke repositori svn harus sesuai dengan prosedur dan proses apa pun yang digunakan tim lainnya. Keuntungan lain dari pendekatan ini adalah bahwa para fanatik DVCS sejati yang sudah menggunakan gateway tanpa memberi tahu Anda sekarang dapat keluar dari lemari :-).

— dfjacobs
sumber

Apakah kita ingin meluangkan waktu untuk berubah? Tidak, terutama tidak ketika kami hanya beralih ke svn dalam 2 tahun terakhir. Terima kasih atas komentar anda

— Matt

1

Sepertinya saya sudah menggunakan alur kerja yang sangat mirip dengan jenis alur kerja yang diadopsi banyak orang setelah mereka mulai menggunakan DVCS.

Dari sudut pandang Anda, DVCS akan memiliki keuntungan signifikan berikut dibandingkan SVN:

Setelah Anda mengkloning repo Anda, banyak operasi dapat dilakukan secara lokal.
- Melihat log repositori tidak perlu menyentuh server svn, jadi bisa sangat cepat.
- Demikian pula, beralih cabang tidak memerlukan akses ke server, klon lokal juga tidak.
Karena cabang hanya jalur yang berbeda sepanjang sejarah, repositori Anda tidak berantakan dengan setiap cabang yang dibuat setiap orang (kami hanya benar-benar memiliki cabang rilis di SVN, tetapi branchesdirektori masih memiliki banyak subdirektori yang tidak lagi relevan).
- Di git, setelah cabang digabungkan kembali dan wasit dihapus, Anda mungkin tidak pernah tahu itu ada di sana.
- Dalam Mercurial Anda memiliki pilihan untuk menamai cabang (dalam hal ini disandikan ke dalam setiap perubahan selamanya) atau hanya membuat cabang (topologi) yang tidak disebutkan namanya, yang diam-diam akan menggabungkan ke dalam sejarah ketika merged kembali ke default( trunk)
Dalam SVN, cabang cabang terlalu tidak jelas untuk berguna. Di gitdan hgmereka hanya setara untuk kursus.
DVCS memahami bahwa pengembangan perangkat lunak adalah DAG , yaitu ketika Anda bergabung, Anda berakhir dengan perubahan dengan banyak orangtua. SVN (setidaknya versi yang saya gunakan) tidak terlalu memahami hal ini.

Pada poin terakhir, katamu

Konflik adalah konflik, saya tidak melihat bagaimana sistem apa pun bisa melakukannya dengan benar sebagian besar waktu kecuali itu cukup cerdas untuk memahami kode.

Dalam beralih dari menggunakan hgsecara eksklusif ke menggunakan svnsendiri dan kemudian gitsvnpengalaman saya bahwa penggabungan jauh lebih sederhana dan bebas masalah dengan hgdan gitsvndaripada dengan mereka svn. Penggabungan dengan svn(setidaknya versi yang kami gunakan) menghasilkan lebih banyak konflik yang perlu diselesaikan secara manual.

Salah satu alasan penggabungan lebih sulit di SVN adalah bahwa itu hanya memberi Anda dua opsi untuk setiap baris yang berbeda,

teks dari cabang yang Anda gabungkan
teks dari cabang yang Anda gabungkan

sementara penggabungan dari DVCS biasanya akan memberi Anda opsi ketiga, yaitu

teks dari nenek moyang yang sama dari kedua cabang yang Anda gabungkan

Jangan meremehkan betapa bermanfaatnya hal ini, ini memberi Anda konteks yang jauh lebih baik untuk perubahan daripada perbedaan sederhana dua arah.

Secara keseluruhan, saya sarankan Anda mencobanya. Dengan alat seperti gitsvndan hgsubversion, Anda bahkan dapat mencobanya dengan repo SVN Anda saat ini .

^{Catatan, membuat klon di tempat pertama adalah royal PItA, tetapi setelah Anda selesai melakukannya, Anda mendapatkan sebagian besar kekuatan DVCS dengan CVCS yang ada.}

— Mark Booth
sumber

1

SVN tidak memunculkan konflik dalam kasus yang Anda sebutkan juga. Itu hanya muncul ketika Anda berdua mengubah baris yang sama. Penggabungan pada umumnya lebih merupakan masalah dengan penggantian nama file / pemindahan atau penambahan / penghapusan dalam svn karena tidak menangani perubahan direktori yang digabung dengan baik. Gabungan SVN memberi Anda lebih banyak opsi daripada 2, biasanya saya menggunakan "gunakan milik mereka kemudian milikku" karena Anda umumnya ingin menyimpan kedua set perubahan, bukan menghapus keduanya!

— gbjbaanb

@ gbjbaanb - Bukan itu yang saya temukan, itulah sebabnya saya memenuhi syarat pengalaman SVN saya at least the version I've used. Pemahaman saya adalah bahwa versi terbaru dari svn tidak mengerti tentang nenek moyang yang sama, tapi saya tidak punya pengalaman itu dan saya menduga ada banyak server di luar sana yang menjalankan versi svn yang memiliki masalah yang sama.

— Mark Booth

Kebetulan, saya suka fakta bahwa dengan hg(dan hampir pasti git, tapi saya belum mencobanya) Anda dapat mengambil file dengan tiga kelas, membaginya menjadi tiga file dengan kelas masing-masing, lalu kemudian menggabungkan perubahan antara cabang dengan File 'gabungan' dan cabang dengan file terpisah sehingga perubahan pada masing-masing kelas dapat diterapkan ke file yang benar. Sihir murni. * 8 ')

— Mark Booth

1

gbjbaanb benar; SVN tidak akan memiliki konflik dalam skenario yang Anda gambarkan. Cukup mudah untuk menunjukkan ini pada diri Anda sendiri.

— Jeremy

@Jeremy @gbjaanb - Apakah bagian yang diedit bekerja lebih baik untuk Anda? Saya tidak akan berdebat dengan Anda tentang bagaimana svnseharusnya penggabungan, saya punya pengalaman sendiri dengan itu svnbaris perintah dan SVNKit di bawah Eclipse di mana hanya dengan menarik pembaruan dapat menghasilkan 'konflik' yang harus diselesaikan secara manual dengan cut dan paste (Saya tidak dapat dengan mudah mengatakan 'Saya ingin kedua perubahan ini, dalam urutan ini).

— Mark Booth

0

Ada satu perubahan penting yang saya perhatikan setelah transisi seperti itu: Saya lebih sering berganti cabang, dan saya melakukan lebih sering daripada yang saya mampu dengan Subversion. Sebagai contoh, ada sejumlah cabang fungsionalitas kecil, yang diorganisasikan secara berurutan, dan saya bisa menghabiskan waktu berbulan-bulan untuk menambahkan bit pada masing-masingnya, dengan mudah mengubah semua itu secara berurutan ke trunk yang terus berubah. Menyusun ulang urutan di mana cabang fungsionalitas digabungkan adalah sepele.

Tetapi, sebenarnya, saya belum benar-benar pindah dari Subversion. Saya hanya menggunakan git sebagai klien svn lokal saya.

— Logika SK
sumber