Menggunakan SVN dengan buruk - apakah Mercurial jawabannya?


13

Di tempat kerja kami menggunakan SVN, tetapi hanya dalam nama. Kami tidak bercabang atau bergabung. Kami menyimpan dua salinan dari repositori, satu berfungsi sebagai cabang "tag" yang disalin ketika kami melakukan penempatan dan disimpan untuk perbaikan bug dan langsung "jenis ini harus ditayangkan langsung" fitur. Kita harus ingat untuk menyalin perubahan yang dibuat dalam satu salinan ke salinan lainnya ("trunk"). Kami memiliki selusin proyek di dalam satu folder di repositori, alih-alih membaginya. Singkatnya satu-satunya hal yang kami gunakan untuk SVN adalah kemampuan untuk melakukan. Yang lainnya dilakukan secara manual.

Saya telah mengevaluasi Mercurial; Saya telah menggunakan Git di masa lalu (saya satu-satunya di tim yang telah menggunakan DVCS), dan saya mengambil Mercurial dengan cepat. Saya berdebat memperkenalkan Mercurial ke seluruh tim sebagai "cara yang lebih baik" dalam melakukan sesuatu karena percabangan itu mudah, penggabungan jauh lebih mudah, dan kami dapat melakukan hal-hal secara lokal sesuai dengan isi hati kami dan hanya mendorong mereka ke pusat bercabang saat mereka siap. Kami akan mendapatkan semua manfaat dari SVN (dan kami juga tidak mendapatkan banyak manfaat saat ini karena tidak ada yang benar-benar memahami SVN) plus untuk fitur-fitur baru kami tidak harus memiliki banyak file yang tidak berversi yang mengambang sehingga kami harus mengembalikan kita dalam masalah. Alur kerjanya tampak sedikit lebih sederhana - kita hanya harus ingat bahwa "Komit" adalah lokal dan "Dorong" seperti komit SVN,

Apakah ini pendekatan yang baik untuk dilakukan? Perlu diingat bahwa tim ini sangat fleksibel dan akan sejalan dengan apa pun yang akan meningkatkan kualitas kerja kami dan membuat kami melakukan hal-hal lebih mudah - CIO bahkan bertanya kepada saya ketika saya menyebutkan bagaimana kami tidak menggunakan SVN untuk potensinya "Apakah ada sesuatu yang lebih baik yang bisa kita gunakan? " jadi dia juga ikut.


13
HgInit - Ini dimulai dengan subversi pendidikan ulang, yang saya pikir Anda akan menemukan berguna.
yannis

20
Apakah Anda tidak takut bahwa mereka akan menggunakan Hg dengan buruk juga?
Oded

6
Saya pikir DVCS akan menjadi ide yang mengerikan untuk situasi Anda, karena kurva pembelajaran lebih tinggi dan Anda jelas sebagai organisasi yang berjuang hanya untuk memanfaatkan fitur dasar SVN. Pindah ke DVCS hanya akan terjadi setelah Anda menggunakan tag, organisasi repositori yang tepat, dan teknik penggabungan yang tepat di SVN dan menemukan bahwa itu masih kurang untuk kebutuhan Anda.
maple_shaft

2
@WayneM Memilih untuk menggunakan SVN melalui DVCS tidak selalu salah. Beberapa orang (termasuk saya) tidak memiliki masalah dengan penggabungan SVN dan menemukan bahwa kompleksitas tambahan dari DVCS melebihi manfaat yang dirasakan, terutama jika Anda adalah tim lokal yang lebih kecil. Saya mungkin tidak akan menganggap DVCS dengan sangat serius sampai saya berakhir di tim pengembangan besar di mana penggabungan merupakan titik yang sangat menyakitkan.
maple_shaft

4
@maple_shaft I will probably not take DVCS very seriously until I end up on a large development teamAtau hingga Anda berakhir di tim terdistribusi. Kami adalah tim kecil (5 orang) yang bekerja dari 3 lokasi (dan kadang-kadang 5, ketika kami merasa tidak ingin turun dari tempat tidur), dan pergantian dari svn ke hg adalah yang menyenangkan ...
yannis

Jawaban:


15

Iya.

Jika Anda mengganti "SVN" dengan "Perforce" di OP Anda, Anda sudah cukup banyak menghadapi situasi ketika saya memulai pekerjaan saya saat ini, bahkan sampai ke penyalinan perubahan manual. Dua tahun kami di Mercurial dan semua orang setuju itu adalah perubahan besar.

Kami memiliki kemampuan untuk bercabang dan menggabungkan per kasus dukungan , yang sangat berguna untuk QA, dan kemampuan untuk membuat sejumlah cabang dan repositori yang dapat dibuang kapan pun kami mau, yang kemudian dapat kami bangun dan verifikasi di server CI kami, kemudian gunakan ke lingkungan cloud test dan verifikasi fungsionalitas. Ini telah sangat bermanfaat dalam hal ketenangan pikiran bahwa ketika kami melakukan penyebaran langsung, kami hampir 100% yakin itu akan berhasil (tanpa masalah lingkungan / DB, yang jelas di luar ruang lingkup VCS).

Pada dasarnya, apa yang kami peroleh dari beralih ke mercurial adalah menghirup ruang. Kita tidak perlu lagi khawatir tentang biaya cabang, atau sesi penggabungan mengerikan yang mau tidak mau harus diikuti, semuanya jauh lebih mudah. Kami juga menggunakan FogBugz cukup banyak sehingga ikatan ke Kiln (lincah host mereka) sangat membantu.

Komentar tentang situs hginit juga tepat, sebagai garis besar untuk alur kerja kontrol versi yang benar-benar berfungsi (dengan asumsi Anda menyesuaikannya untuk alur kerja QA khusus perusahaan Anda).

Satu-satunya kelemahan yang mungkin terjadi dalam kontrol versi pemindahan adalah bahwa Anda akan membutuhkan seseorang yang benar-benar merupakan kekuatan pendorong di balik perubahan, yang senang membaca materi pelajaran dan benar-benar menggunakan perkakas dengan potensi terbaiknya, yang tampaknya ingin Anda lakukan. melakukan.

Saya tidak setuju dengan komentar tentang ukuran tim dan distribusi tim yang berkaitan dengan apakah akan menggunakan DCVS juga. Sungguh, ini tentang distribusi KODE. Jika Anda memiliki beberapa siklus pengembangan yang terjadi secara paralel, baik mendukung kasing pada sistem lama, atau banyak fitur atau bahkan sistem baru (yang menurut Anda lakukan), Anda akan mendapat manfaat dari menggunakan DVCS.


3
-1, jika pengembang sudah mengalami masalah dengan Subversion, sangat tidak mungkin mereka akan "mendapatkan" sistem yang lebih kompleks. Jawaban yang benar adalah, seperti komentar pada pertanyaan mengatakan, pendidikan ulang tentang bagaimana Subversion (dan VCS secara umum) bekerja ...
Izkata

1
@ Edwoodcock, saya pikir apa yang Anda amati mungkin benar-benar disebabkan oleh fakta bahwa tim Anda harus memulai dengan "batu tulis yang bersih". Perubahan komprehensif VCS menjadi lincah berarti bahwa setiap orang harus mulai segar dan tidak bisa lagi bergantung pada kebiasaan buruk yang mereka gunakan di SVN. Sering kali lebih mudah untuk mengatasi kebiasaan buruk "memulai kembali" dalam konteks lain (dalam hal ini lincah).
Angelo

2
@EdWoodcock: Perforce mungkin memiliki percabangan terburuk dari semua VCS yang masih digunakan. Bercabang di SVN jauh lebih mudah.
kevin cline

1
Apa pun sistem kontrol versi yang digunakan, saya pikir penting untuk "meletakkan aturan" dan menghabiskan waktu untuk membahas semua skenario penggunaan dengan tim Anda. Orang tidak dilahirkan dengan mengetahui cara melakukan cabang, tag dan check-in, tim yang berbeda melakukan hal-hal ini dengan cara yang berbeda dan sistem VCS tidak memaksakan satu alur kerja lebih dari yang lain. Jika anggota tim tidak semua berada di halaman yang sama dalam hal harapan dan penggunaan, kontrol versi menjadi mimpi buruk. Ini adalah masalah yang umum untuk SEMUA sistem VCS.
Angelo

1
@ ChrisS Perumpamaan itu lebih berlaku untuk VCS standar di mana ada biaya percabangan. Plus, ini berbicara tentang percabangan, melakukan, lalu menggabungkan lagi, yang <i> Anda lakukan setiap kali Anda mengkloning </i> dalam DVCS. Plus, saya baru saja menguraikan mengapa pendekatan ini benar-benar bekerja untuk kita; bersikap dogmatis tentang metodologi cukup konyol.
Ed James

21

Alat yang berbeda mungkin tidak akan menyelesaikan masalah Anda, saya katakan Anda harus membaca artikel ini, saya merasa paling bermanfaat:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Saya pikir poin utama dari artikel ini dirangkum di sini, tapi tolong baca:

In The End: Not Really About The Tools

Dalam semua waktu yang saya habiskan untuk bekerja dan mengintegrasikan berbagai sistem kontrol sumber, saya sampai pada satu kesimpulan: ini bukan alatnya, melainkan bagaimana Anda menggunakannya. Itu pernyataan yang sangat usang, tetapi tampaknya benar di sini. Ketika digunakan untuk mengelola perubahan kode sumber dengan benar - pelabelan untuk bangunan, percabangan dengan pengecualian, dll. - bahkan sistem kontrol sumber yang paling lambat (* batuk * SourceSafe * batuk *) akan jauh mengungguli set-up Mercurial dengan banyak komit serampangan dan dilakukan mendorong.


6
+1, ini sebenarnya bukan tentang alat. SVN sangat mampu seperti halnya terpaksa.
Angelo

1
Ini semua tentang orang, bukan alat. Saya telah melihat proyek yang dikelola dengan baik masih menggunakan Sistem Versi Serentak untuk kontrol versi, serta proyek mengerikan yang menjalankan GIT atau Mercurial ..
Alexander Galkin

Ini bukan benar-benar tentang alat, kecuali jika Anda punya yang lebih unggul untuk memuji penyedia kontrol sumber seperti github, bitbucket
Chris S

3
Sementara saya setuju bahwa itu adalah bagaimana Anda menggunakan alat Anda yang diperhitungkan, itu juga merupakan kasus di mana alat yang berbeda mengarahkan Anda ke arah yang berbeda. Alat-alat seperti Mercurial menuntun Anda ke jalan kesederhanaan dan fleksibilitas. Git menuntun Anda ke jalan kompleksitas tetapi fleksibilitas ekstrim, Subversion membuat beberapa hal lebih mudah daripada yang lain, sehingga menjauhkan Anda dari hal-hal yang sulit dan fiddly, sementara Visual Sourcesafe membawa Anda ke jalan yang tidak fleksibel dan frustasi. * 8 ')
Mark Booth

10

Tidak. Teknologi jarang sekali memecahkan masalah seperti ini.

Mercurial lebih kompleks daripada Subversion (ya, percabangan dan penggabungan lebih baik, dan mungkin lebih mudah, tetapi model Subversion jauh lebih sederhana daripada Mercurial). Jika Anda menggunakan Subversion dengan cara braindead sedemikian rupa, Anda mungkin akhirnya menggunakan Mercurial:

  • a) Cukup atau lebih baik
  • b) Tidak memadai, tetapi lebih baik daripada penggunaan Subversion Anda saat ini
  • c) Tidak memadai seperti sekarang
  • d) Lebih buruk dari sekarang

c) dan d) terdengar seperti hasil yang paling mungkin. Tuliskan mengapa Anda berpikir Anda akan berakhir pada a) atau b).


5

Saya tidak dapat berbicara tentang bagaimana tim besar bekerja, tetapi untuk tim kecil banyak masalah SVN besar itu sebenarnya bukan masalah SVN ... Itu masalah pengembangan. Jika Anda tidak mengikuti standar pengembangan modern (yang paling penting, melakukan integrasi terus-menerus), maka mengubah versi menjadi kekacauan persis yang Anda gambarkan ... Sebelum melompat ke sistem baru, pastikan untuk melakukan analisis akar masalah yang sebenarnya pada masalah Anda ...


3

Tidak. Alat bukan pengganti metodologi.

Jika Anda tidak menggunakan Subversion sebagai SCM , Anda juga tidak bisa menggunakan Mercurial (dan itu kemungkinan besar akan terjadi)


2

SVN dapat melakukan apa yang perlu Anda lakukan dan tidak perlu mengubah kuda mid-stream untuk pembayaran yang meragukan.

Apa pun yang Anda lakukan, Anda harus mengatasi masalah kepercayaan. Seseorang harus dapat meyakinkan semua orang untuk mengubah alur kerja mereka. Ini tidak mudah bahkan dalam keadaan terbaik, bahkan jika Anda memiliki logika dan fakta di pihak Anda. Ini adalah salah satu hal tersulit untuk dilakukan dalam suatu organisasi. Jika Anda merusaknya atau menjadi kasar, Anda kehilangan kepercayaan dan akan sangat sulit untuk mendapatkan kembali kepercayaan itu.

Ada beberapa hal yang saya tahu orang telah mencoba dengan sukses. Mungkin salah satu dari mereka akan bekerja untuk tim Anda:

  1. Membawa "pelatih" untuk menyediakan serangkaian lokakarya untuk tim. Ini kemungkinan akan menjadi orang eksternal (ironisnya, seringkali lebih mudah bagi banyak tim untuk memercayai orang luar daripada memercayai seseorang dalam tim). Itu haruslah seseorang yang mengetahui barang-barangnya dari dalam ke luar dan yang secara efektif dapat mengajarkan keterampilan ini kepada orang-orang di semua tingkatan pemahaman dan menyusun rencana pragmatis untuk meluncurkan VCS baru (*) ke alur kerja tim.

  2. Mulai proyek "skunk-works" untuk menguji-drive dan memvalidasi VCS baru pada proyek sampingan kecil. Pilih beberapa pengembang "alfa" yang bersedia mencoba hal-hal baru dan tidak keberatan memeras banyak percobaan yang tidak berhasil. Ketika skunk-work dapat menunjukkan peningkatan alur kerja yang tak terbantahkan oleh CONCRETE, maka Anda dapat mencoba untuk meluncurkannya ke anggota tim lainnya dan Anda memiliki beberapa penginjil untuk membantu Anda melakukannya.

(*) oleh "VCS baru" Saya tidak harus berarti lincah atau git, itu juga bisa SVN (dilakukan dengan benar).

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.