Apa yang dilihat orang-orang di sini sebagai kekuatan dan kelemahan relatif Git, Mercurial, dan Bazaar?
Dalam mempertimbangkan masing-masing satu sama lain dan melawan sistem kontrol versi seperti SVN dan Perforce, masalah apa yang harus dipertimbangkan?
Dalam merencanakan migrasi dari SVN ke salah satu sistem kontrol versi terdistribusi ini, faktor apa yang akan Anda pertimbangkan?
Jawaban:
Git sangat cepat, berskala sangat baik, dan sangat transparan tentang konsepnya. Sisi negatifnya adalah kurva belajarnya relatif curam. Porta Win32 tersedia, tetapi bukan warga negara kelas satu. Git memperlihatkan hashes sebagai nomor versi kepada pengguna; ini memberikan jaminan (bahwa satu hash selalu mengacu pada konten yang sama persis; penyerang tidak dapat mengubah riwayat tanpa terdeteksi), tetapi dapat merepotkan pengguna. Git memiliki konsep unik dalam melacak konten file, meskipun konten tersebut berpindah antar file, dan melihat file sebagai objek level pertama, tetapi tidak melacak direktori. Masalah lain dengan git adalah operasi yang banyak (seperti rebase) yang memudahkan untuk mengubah riwayat (dalam arti tertentu - konten yang dirujuk oleh hash tidak akan pernah berubah, tetapi referensi ke hash tersebut mungkin hilang); beberapa puritan (termasuk saya) tidak terlalu menyukainya.
Bazaar cukup cepat (sangat cepat untuk pepohonan dengan riwayat yang dangkal, tetapi saat ini berskala buruk dengan panjang riwayat), dan mudah dipelajari bagi mereka yang terbiasa dengan antarmuka baris perintah SCM tradisional (CVS, SVN, dll). Win32 dianggap sebagai target kelas satu oleh tim pengembangannya. Ia memiliki arsitektur yang dapat dicolokkan untuk berbagai komponen, dan sering mengganti format penyimpanannya; ini memungkinkan mereka untuk memperkenalkan fitur-fitur baru (seperti dukungan yang lebih baik untuk integrasi dengan sistem kontrol revisi berdasarkan konsep yang berbeda) dan meningkatkan kinerja. Tim Bazaar mempertimbangkan pelacakan direktori dan mengganti nama dukungan fungsionalitas kelas satu. Meskipun pengenal ID revisi unik global tersedia untuk semua revisi, pemberitahuan lokal-pohon (nomor revisi standar, lebih mirip dengan yang digunakan oleh svn atau SCM konvensional lainnya) digunakan sebagai pengganti hash konten untuk mengidentifikasi revisi. Bazaar memiliki dukungan untuk "pembayaran ringan", di mana riwayat disimpan di server jarak jauh alih-alih disalin ke sistem lokal dan secara otomatis dirujuk melalui jaringan bila diperlukan; saat ini, ini unik di antara DSCM.
Keduanya memiliki beberapa bentuk integrasi SVN yang tersedia; namun, bzr-svn jauh lebih mampu daripada git-svn, sebagian besar karena revisi format backend yang diperkenalkan untuk tujuan tersebut. [Pembaruan, per 2014: SubGit produk komersial pihak ketiga menyediakan antarmuka dua arah antara SVN dan Git yang sebanding dalam kesetiaan dengan bzr-svn, dan jauh lebih halus; Saya sangat merekomendasikan penggunaannya daripada git-svn ketika anggaran dan batasan lisensi mengizinkan].
Saya belum pernah menggunakan Mercurial secara ekstensif, dan karenanya tidak dapat mengomentarinya secara detail - kecuali untuk dicatat bahwa, seperti Git, memiliki hash konten yang ditujukan untuk revisi; juga seperti Git, ia tidak memperlakukan direktori sebagai objek kelas satu (dan tidak dapat menyimpan direktori kosong). Namun, ini lebih cepat daripada DSCM lain kecuali Git, dan memiliki integrasi IDE yang jauh lebih baik (terutama untuk Eclipse) daripada pesaingnya. Mengingat karakteristik kinerjanya (yang hanya sedikit tertinggal di belakang Git) dan dukungan lintas platform dan IDE-nya yang superior, Mercurial mungkin menarik untuk tim dengan jumlah anggota win32-centric atau terikat IDE yang signifikan.
Satu perhatian dalam bermigrasi dari SVN adalah bahwa frontend GUI SVN dan integrasi IDE lebih matang daripada SCM terdistribusi mana pun. Selain itu, jika saat ini Anda banyak menggunakan otomatisasi skrip precommit dengan SVN (yaitu, pengujian unit harus lulus sebelum komit dapat dilanjutkan), Anda mungkin ingin menggunakan alat yang mirip dengan PQM untuk mengotomatiskan permintaan penggabungan ke cabang bersama Anda.
SVK adalah DSCM yang menggunakan Subversion sebagai penyimpanan pendukungnya, dan memiliki integrasi yang cukup baik dengan alat yang berpusat pada SVN. Namun, ini memiliki kinerja dan karakteristik skalabilitas yang jauh lebih buruk daripada DSCM utama lainnya (bahkan Darcs), dan harus dihindari untuk proyek yang kemungkinan besar akan bertambah besar dalam hal panjang riwayat atau jumlah file.
[Tentang penulis: Saya menggunakan Git dan Perforce untuk bekerja, dan Bazaar untuk proyek pribadi saya dan sebagai perpustakaan tertanam; bagian lain dari organisasi atasan saya menggunakan Mercurial dengan berat. Dalam kehidupan sebelumnya saya membangun banyak otomatisasi di sekitar SVN; sebelumnya saya memiliki pengalaman dengan GNU Arch, BitKeeper, CVS dan lainnya. Git pada awalnya agak tidak tepat - rasanya seperti GNU Arch karena merupakan lingkungan konsep-berat, sebagai lawan dari toolkit yang dibangun untuk menyesuaikan dengan pilihan alur kerja pengguna - tetapi sejak itu saya menjadi cukup nyaman dengan Itu].
Steve Streeting dari proyek Ogre 3D baru saja (9/28/2009) menerbitkan entri blog tentang topik ini di mana dia melakukan perbandingan yang hebat dan bahkan menyerahkan Git, Mercurial dan Bazaar .
Pada akhirnya dia menemukan kekuatan dan kelemahan dengan ketiganya dan tidak ada pemenang yang jelas. Sisi positifnya, dia memberikan meja yang bagus untuk membantu Anda memutuskan mana yang akan Anda pilih.
Ini adalah bacaan singkat dan saya sangat merekomendasikannya.
Apa yang dilihat orang-orang di sini sebagai kekuatan dan kelemahan relatif Git, Mercurial, dan Bazaar?
Menurut pendapat saya, kekuatan Git adalah desain dasarnya yang bersih dan serangkaian fitur yang sangat kaya. Menurut saya, ini juga merupakan dukungan terbaik untuk repositori multi-cabang dan mengelola alur kerja cabang-berat. Ini sangat cepat dan memiliki ukuran repositori kecil.
Ini memiliki beberapa fitur yang berguna tetapi membutuhkan usaha untuk menggunakannya. Itu termasuk ara pementasan menengah yang terlihat (indeks) antara area kerja dan database repositori, yang memungkinkan resolusi penggabungan yang lebih baik dalam kasus yang lebih rumit, comitting inkremental, dan comitting dengan pohon kotor; mendeteksi penggantian nama dan salinan menggunakan heuristik kesamaan daripada melacaknya menggunakan beberapa jenis id file, yang berfungsi dengan baik dan yang memungkinkan terjadinya kesalahan (anotasi) yang dapat mengikuti pergerakan kode di seluruh file dan tidak hanya penggantian nama secara grosir.
Salah satu kekurangannya adalah dukungan MS Windows tertinggal dan tidak penuh. Kerugian lain yang dirasakan adalah bahwa itu tidak didokumentasikan dengan baik seperti misalnya Mercurial, dan kurang ramah pengguna daripada kompetisi, tetapi berubah.
Menurut pendapat saya, kekuatan Mercurial terletak pada kinerja yang baik dan ukuran repositori yang kecil, dalam dukungan MS Windows yang baik.
Kekurangan utama menurut pendapat saya adalah fakta bahwa cabang lokal (banyak cabang dalam satu repositori) masih warga kelas dua, dan dengan cara yang aneh dan rumit mengimplementasikan tag. Juga cara menangani penggantian nama file adalah suboptimal (tapi migrasi ini telah berubah). Mercurial tidak mendukung penggabungan gurita (dengan lebih dari dua orang tua).
Dari apa yang saya dengar dan baca, keuntungan utama Bazaar adalah dukungan yang mudah untuk alur kerja terpusat (yang juga merugikan, dengan konsep terpusat terlihat di tempat yang tidak semestinya), melacak penggantian nama file dan direktori.
Kerugian utamanya adalah kinerja dan ukuran repositori untuk repositori besar dengan riwayat nonlinier yang panjang (kinerja meningkat setidaknya untuk repositori yang tidak terlalu besar), fakta bahwa paradigma default adalah satu peternakan per repositori (Anda dapat mengaturnya untuk berbagi data, meskipun) , dan konsep terpusat (tapi itu juga dari apa yang saya dengar berubah).
Git ditulis dalam C, skrip shell dan Perl, dan dapat di-script; Mercurial ditulis dalam C (inti, untuk kinerja) dan Python, dan menyediakan API untuk ekstensi; Bazaar ditulis dengan Python, dan menyediakan API untuk ekstensi.
Dalam mempertimbangkan masing-masing satu sama lain dan melawan sistem kontrol versi seperti SVN dan Perforce, masalah apa yang harus dipertimbangkan?
Sistem kontrol versi seperti Subversion (SVN), Perforce, atau ClearCase adalah sistem kontrol versi terpusat . Git, Mercurial, Bazaar (dan juga Darcs, Monotone dan BitKeeper) adalah sistem kontrol versi terdistribusi . Sistem kontrol versi terdistribusi memungkinkan jangkauan alur kerja yang lebih luas. Mereka mengizinkan untuk menggunakan "publikasikan saat siap". Mereka memiliki dukungan yang lebih baik untuk percabangan dan penggabungan, dan untuk alur kerja dengan banyak cabang. Anda tidak perlu mempercayai orang yang memiliki akses komitmen untuk bisa mendapatkan kontribusi dari mereka dengan cara yang mudah.
Dalam merencanakan migrasi dari SVN ke salah satu sistem kontrol versi terdistribusi ini, faktor apa yang akan Anda pertimbangkan?
Salah satu faktor yang mungkin ingin Anda pertimbangkan adalah dukungan untuk inetracting dengan SVN; Git memiliki git-svn, Bazaar memiliki bzr-svn, dan Mercurial memiliki ekstensi hgsubversion.
Penafian: Saya adalah pengguna Git dan kontributor kecil, dan menonton (dan berpartisipasi di) milis git. Saya tahu Mercurial dan Bazaar hanya dari dokumentasi mereka, berbagai diskusi di IRC dan milis, dan posting blog dan artikel yang membandingkan berbagai sistem kontrol versi (beberapa di antaranya terdaftar di halaman Perbandingan Git di Git Wiki).
InfoQ memiliki perbandingan yang bagus .
Mercurial dan Bazaar sangat mirip di permukaan. Keduanya menyediakan kontrol versi terdistribusi dasar, seperti pada komit offline dan menggabungkan beberapa cabang, keduanya ditulis dalam python dan keduanya lebih lambat dari git. Ada banyak perbedaan setelah Anda mempelajari kodenya, tetapi, untuk tugas-tugas rutin Anda sehari-hari, mereka secara efektif sama, meskipun Mercurial tampaknya memiliki sedikit lebih banyak momentum.
Git, yah, bukan untuk yang belum tahu. Ini jauh lebih cepat daripada Mercurial dan Bazaar, dan ditulis untuk mengelola kernel Linux. Ini adalah yang tercepat dari ketiganya dan juga yang paling kuat dari ketiganya, dengan selisih yang cukup besar. Alat manipulasi log dan komit Git tidak tertandingi. Namun, ini juga yang paling rumit dan paling berbahaya untuk digunakan. Sangat mudah untuk kehilangan komit atau merusak repositori, terutama jika Anda tidak memahami cara kerja git.
Lihatlah perbandingan yang dibuat baru-baru ini oleh pengembang Python: http://wiki.python.org/moin/DvcsComparison . Mereka memilih Mercurial berdasarkan tiga alasan penting:
Pilihan untuk menggunakan Mercurial dibuat karena tiga alasan penting:
- Menurut survei kecil, pengembang Python lebih tertarik menggunakan Mercurial daripada di Bazaar atau Git.
- Mercurial ditulis dengan Python, yang sejalan dengan kecenderungan python-dev untuk 'makan dogfood mereka sendiri'.
- Mercurial secara signifikan lebih cepat daripada bzr (lebih lambat dari git, meskipun dengan perbedaan yang jauh lebih kecil).
- Mercurial lebih mudah dipelajari untuk pengguna SVN daripada Bazaar.
Hal penting yang hilang dalam bazaar adalah cp. Anda tidak dapat memiliki banyak file yang berbagi riwayat yang sama, seperti yang Anda miliki di SVN, lihat misalnya di sini dan di sini . Jika Anda tidak berencana untuk menggunakan cp, bzr adalah pengganti yang bagus (dan sangat mudah digunakan) untuk svn.
Saya menggunakan Bazaar untuk beberapa waktu yang sangat saya sukai tetapi itu hanya proyek yang lebih kecil dan bahkan kemudian cukup lambat. Sangat mudah dipelajari, tetapi tidak super cepat. Ini sangat x-platform.
Saat ini saya menggunakan Git yang sangat saya sukai karena versi 1.6 membuatnya lebih mirip dengan VCS lain dalam hal perintah yang digunakan.
Saya rasa perbedaan utama pengalaman saya dalam menggunakan DVCS adalah ini:
Singkatnya, Bzr sangat bagus ketika saya memotong gigi saya di DVCS tetapi saya sekarang sangat senang dengan Git dan Github.
Ini adalah pertanyaan besar yang sangat bergantung pada konteks yang akan membutuhkan banyak waktu bagi Anda untuk mengetik ke salah satu kotak teks kecil ini. Selain itu, ketiganya tampak sangat mirip saat digunakan untuk hal-hal biasa yang dilakukan sebagian besar pemrogram, jadi memahami perbedaannya pun memerlukan pengetahuan yang cukup esoteris.
Anda mungkin akan mendapatkan jawaban yang jauh lebih baik jika Anda dapat memecah analisis Anda terhadap alat-alat ini hingga ke titik di mana Anda memiliki pertanyaan yang lebih spesifik.
Bazaar adalah IMHO lebih mudah dipelajari daripada git. Git memiliki dukungan yang bagus di github.com.
Saya pikir Anda harus mencoba menggunakan keduanya dan memutuskan mana yang paling cocok untuk Anda.
Apa yang dilihat orang-orang di sini sebagai kekuatan dan kelemahan relatif Git, Mercurial, dan Bazaar?
Ini adalah pertanyaan yang sangat terbuka, berbatasan dengan flamebait.
Git tercepat, tetapi ketiganya cukup cepat. Bazaar adalah yang paling fleksibel (memiliki dukungan baca-tulis transparan untuk repositori SVN) dan sangat peduli dengan pengalaman pengguna. Mercurial ada di suatu tempat di tengah.
Ketiga sistem ini memiliki banyak fanboy. Saya pribadi seorang fanboy Bazaar.
Dalam mempertimbangkan masing-masing satu sama lain dan melawan sistem kontrol versi seperti SVN dan Perforce, masalah apa yang harus dipertimbangkan?
Yang pertama adalah sistem terdistribusi. Yang terakhir adalah sistem terpusat. Selain itu, Perforce adalah hak milik sementara yang lainnya bebas seperti dalam ucapan .
Sentralisasi versus desentralisasi adalah pilihan yang jauh lebih penting daripada sistem apa pun yang Anda sebutkan dalam kategorinya.
Dalam merencanakan migrasi dari SVN ke salah satu sistem kontrol versi terdistribusi ini, faktor apa yang akan Anda pertimbangkan?
Pertama, kurangnya pengganti yang bagus untuk TortoiseSVN. Meskipun Bazaar sedang mengerjakan varian Tortoise mereka sendiri , tetapi belum ada, per September 2008.
Kemudian, melatih orang-orang kunci tentang bagaimana menggunakan sistem desentralisasi akan mempengaruhi pekerjaan mereka.
Terakhir, integrasi dengan sistem lainnya, seperti pelacak masalah, sistem pembuatan malam, sistem pengujian otomatis, dll.
Masalah utama Anda adalah bahwa ini adalah SCM Terdistribusi , dan karena itu memerlukan sedikit perubahan pada pola pikir pengguna. Begitu orang terbiasa dengan gagasan, detail teknis dan pola penggunaan akan diterapkan, tetapi jangan meremehkan rintangan awal itu, terutama dalam pengaturan perusahaan. Ingat, semua masalah adalah masalah manusia.
ddaa.myopenid.com menyebutkannya secara sepintas, tapi saya pikir perlu disebutkan lagi: Bazaar dapat membaca dan menulis ke repositori SVN jarak jauh. Itu berarti Anda dapat menggunakan Bazaar secara lokal sebagai bukti konsep sementara anggota tim lainnya masih menggunakan Subversion.
EDIT: Hampir semua alat sekarang memiliki beberapa cara untuk berinteraksi dengan SVN, tetapi saya sekarang memiliki pengalaman pribadi yang git svnbekerja dengan sangat baik. Saya telah menggunakannya selama berbulan-bulan, dengan sedikit cegukan.
Ada video bagus oleh Linus Torvalds di git. Dia adalah pencipta Git jadi inilah yang dia promosikan tetapi dalam video dia menjelaskan apa itu SCM yang didistribusikan dan mengapa mereka lebih baik daripada yang terpusat. Ada banyak hal yang membandingkan git (mercurial dianggap OK) dan cvs / svn / perforce. Ada juga pertanyaan dari audiens tentang migrasi ke SCM terdistribusi.
Saya menemukan materi ini mencerahkan dan saya dijual ke SCM terdistribusi. Namun terlepas dari upaya Linus, pilihan saya lincah. Alasannya adalah bitbucket.org, saya merasa lebih baik (lebih murah hati) daripada github.
Saya perlu mengatakan di sini sepatah kata peringatan: Linus memiliki gaya yang cukup agresif, saya pikir dia ingin melucu tetapi saya tidak tertawa. Selain itu, videonya bagus jika Anda baru mengenal SCM terdistribusi dan berpikir untuk pindah dari SVN.
Sistem kontrol versi terdistribusi (DVCS) memecahkan masalah yang berbeda dari VCS Terpusat. Membandingkannya seperti membandingkan palu dan obeng.
Sistem VCS terpusat dirancang dengan maksud bahwa ada Satu Sumber Sejati yang Terberkati, dan karenanya Baik. Semua pengembang bekerja (checkout) dari sumber itu, dan kemudian menambahkan (melakukan) perubahan mereka, yang kemudian menjadi Diberkati yang serupa. Satu-satunya perbedaan nyata antara CVS, Subversion, ClearCase, Perforce, VisualSourceSafe, dan semua CVCS lainnya adalah dalam alur kerja, kinerja, dan integrasi yang ditawarkan setiap produk.
Sistem VCS terdistribusi dirancang dengan maksud bahwa satu repositori sama baiknya dengan yang lain, dan penggabungan dari satu repositori ke repositori lainnya hanyalah bentuk komunikasi lain. Setiap nilai semantik yang repositori harus dipercaya dipaksakan dari luar melalui proses, bukan oleh perangkat lunak itu sendiri.
Pilihan sebenarnya antara menggunakan satu jenis atau lainnya adalah organisasi - jika proyek atau organisasi Anda menginginkan kontrol terpusat, maka DVCS adalah non-starter. Jika pengembang Anda diharapkan bekerja di seluruh negara / dunia, tanpa koneksi broadband aman ke repositori pusat, maka DVCS mungkin adalah penyelamat Anda. Jika Anda membutuhkan keduanya, Anda fsck.