Saya telah menggunakan Subversion selama beberapa tahun dan setelah menggunakan SourceSafe , saya suka Subversion. Dikombinasikan dengan TortoiseSVN , saya tidak bisa membayangkan bagaimana bisa lebih baik.
Namun ada semakin banyak pengembang yang mengklaim bahwa Subversion memiliki masalah dan bahwa kita harus pindah ke generasi baru dari sistem kontrol versi terdistribusi, seperti Git .
Bagaimana cara Git meningkat pada Subversi?
Jawaban:
Git tidak lebih baik dari Subversi. Tetapi juga tidak lebih buruk. Ini berbeda.
Perbedaan utamanya adalah desentralisasi. Bayangkan Anda adalah seorang pengembang di jalan, Anda mengembangkan di laptop Anda dan Anda ingin memiliki kontrol sumber sehingga Anda dapat kembali 3 jam.
Dengan Subversion, Anda memiliki Masalah: Gudang SVN mungkin berada di lokasi yang tidak dapat Anda jangkau (di perusahaan Anda, dan saat ini Anda tidak memiliki internet), Anda tidak dapat melakukan. Jika Anda ingin membuat salinan kode Anda, Anda harus benar-benar menyalin / menempelnya.
Dengan Git, Anda tidak memiliki masalah ini. Salinan lokal Anda adalah repositori, dan Anda dapat berkomitmen padanya dan mendapatkan semua manfaat dari kontrol sumber. Saat Anda mendapatkan kembali konektivitas ke repositori utama, Anda dapat melakukan komitmen terhadapnya.
Ini terlihat bagus pada awalnya, tetapi ingatlah kompleksitas yang ditambahkan pada pendekatan ini.
Git tampaknya menjadi "baru, berkilau, keren". Ini sama sekali tidak buruk (memang ada alasan mengapa Linus menulisnya untuk pengembangan Kernel Linux), tetapi saya merasa bahwa banyak orang yang naik kereta "Distributed Source Control" hanya karena itu baru dan ditulis oleh Linus Torvalds, tanpa benar-benar mengetahui mengapa / jika itu lebih baik.
Subversi memiliki Masalah, tetapi begitu juga Git, Mercurial, CVS, TFS atau apa pun.
Sunting: Jadi jawaban ini sekarang berumur satu tahun dan masih menghasilkan banyak upvotes, jadi saya pikir saya akan menambahkan beberapa penjelasan lagi. Pada tahun terakhir sejak menulis ini, Git telah memperoleh banyak momentum dan dukungan, terutama karena situs seperti GitHub benar-benar lepas landas. Saya menggunakan Git dan Subversion saat ini dan saya ingin berbagi wawasan pribadi.
Pertama-tama, Git bisa sangat membingungkan pada awalnya ketika bekerja secara desentralisasi. Apa itu remote? dan Bagaimana cara mengatur repositori awal dengan benar? dua pertanyaan yang muncul di awal, terutama dibandingkan dengan "svnadmin create" sederhana SVN, "git init" Git dapat mengambil parameter --bare dan - shared yang tampaknya menjadi cara "tepat" untuk mengatur terpusat gudang. Ada alasan untuk ini, tetapi menambah kompleksitas. Dokumentasi perintah "checkout" sangat membingungkan bagi orang-orang yang berubah - cara yang "tepat" tampaknya adalah "git clone", sementara "git checkout" tampaknya beralih cabang.
Git BENAR-BENAR bersinar ketika Anda didesentralisasi. Saya memiliki server di rumah dan Laptop di jalan, dan SVN tidak berfungsi dengan baik di sini. Dengan SVN, saya tidak dapat memiliki kontrol sumber lokal jika saya tidak terhubung ke repositori (Ya, saya tahu tentang SVK atau tentang cara menyalin repo). Dengan Git, itu adalah mode default. Ini adalah perintah tambahan (git commit melakukan secara lokal, sedangkan git push origin master mendorong cabang master ke remote bernama "origin").
Seperti yang dikatakan di atas: Git menambah kompleksitas. Dua mode pembuatan repositori, checkout vs. clone, commit vs push ... Anda harus tahu perintah mana yang bekerja secara lokal dan yang bekerja dengan "server" (Saya berasumsi kebanyakan orang masih suka "master-repositori" sentral) ).
Juga, perkakasnya masih kurang, setidaknya di Windows. Ya, ada Visual Studio AddIn, tapi saya masih menggunakan git bash dengan msysgit.
SVN memiliki keuntungan bahwa ini JAUH lebih mudah untuk dipelajari: Ada repositori Anda, semua perubahan untuk menuju itu, jika Anda tahu cara membuat, melakukan, dan checkout dan Anda siap untuk pergi dan dapat mengambil barang-barang seperti percabangan, memperbarui dll. Nanti di.
Git memiliki keuntungan bahwa JAUH lebih cocok jika beberapa pengembang tidak selalu terhubung ke repositori master. Juga, ini jauh lebih cepat daripada SVN. Dan dari apa yang saya dengar, dukungan percabangan dan penggabungan jauh lebih baik (yang diharapkan, karena ini adalah alasan utama yang ditulis).
Ini juga menjelaskan mengapa ia mendapat banyak buzz di Internet, karena Git sangat cocok untuk proyek-proyek Open Source: Hanya Fork itu, komit perubahan Anda ke Fork Anda sendiri, dan kemudian minta pengelola proyek asli untuk menarik perubahan Anda. Dengan Git, ini hanya berfungsi. Sungguh, coba di Github, ini ajaib.
Apa yang saya juga lihat adalah Git-SVN Bridges: Repositori pusat adalah repo Subversion, tetapi pengembang lokal bekerja dengan Git dan jembatan kemudian mendorong perubahan mereka ke SVN.
Tetapi bahkan dengan tambahan panjang ini, saya masih mendukung pesan inti saya: Git tidak lebih baik atau lebih buruk, hanya saja berbeda. Jika Anda memiliki kebutuhan untuk "Kontrol Sumber Offline" dan kesediaan untuk meluangkan waktu tambahan mempelajarinya, itu fantastis. Tetapi jika Anda memiliki Kontrol Sumber yang terpusat secara ketat dan / atau berjuang untuk memperkenalkan Kontrol Sumber di tempat pertama karena rekan kerja Anda tidak tertarik, maka kesederhanaan dan perkakas yang sangat baik (setidaknya pada Windows) dari SVN bersinar.
Dengan Git, Anda bisa melakukan apa saja secara offline, karena setiap orang memiliki repositori sendiri.
Membuat cabang dan menggabungkan antar cabang sangat mudah.
Bahkan jika Anda tidak memiliki hak komit untuk proyek, Anda masih dapat memiliki repositori online Anda sendiri, dan menerbitkan "permintaan push" untuk tambalan Anda. Setiap orang yang menyukai tambalan Anda dapat menariknya ke dalam proyek mereka, termasuk pengelola resmi.
Itu sepele untuk garpu proyek, memodifikasinya, dan masih terus menggabungkan perbaikan bug dari cabang HEAD.
Git bekerja untuk pengembang kernel Linux. Itu berarti sangat cepat (harus), dan skala ke ribuan kontributor. Git juga menggunakan lebih sedikit ruang (hingga 30 kali lebih sedikit ruang untuk repositori Mozilla).
Git sangat fleksibel, sangat TIMTOWTDI (Ada lebih dari satu cara untuk melakukannya). Anda dapat menggunakan alur kerja apa pun yang Anda inginkan, dan Git akan mendukungnya.
Akhirnya, ada GitHub , situs hebat untuk hosting repositori Git Anda.
Kerugian dari Git:
Jawaban lain telah melakukan pekerjaan yang baik untuk menjelaskan fitur inti dari Git (yang hebat). Tetapi ada juga banyak cara kecil yang membuat Git berperilaku lebih baik dan membantu menjaga hidup saya lebih waras. Inilah beberapa hal kecil:
git mvdan git rm.
" Mengapa Git lebih baik daripada X " menguraikan berbagai pro dan kontra dari Git vs SCM lainnya.
Secara singkat:
Ada beberapa kelemahannya:
Dalam penggunaan yang paling sederhana, Subversion dan Git hampir sama. Tidak ada banyak perbedaan antara:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
dan
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Di mana Git benar-benar bersinar bercabang dan bekerja dengan orang lain.
Google Tech Talk: Linus Torvalds on git
http://www.youtube.com/watch?v=4XpnKHJAok8
Halaman perbandingan Git Wiki
Yah, sudah didistribusikan. Benchmark menunjukkan bahwa itu jauh lebih cepat (mengingat sifatnya yang terdistribusi, operasi seperti diffs dan log semuanya lokal jadi tentu saja lebih cepat dalam hal ini), dan folder yang bekerja lebih kecil (yang masih membuat saya berpikir).
Saat Anda mengerjakan subversi, atau sistem kontrol revisi klien / server lain, Anda pada dasarnya membuat copy pekerjaan di mesin Anda dengan memeriksa revisi. Ini mewakili snapshot dalam waktu seperti apa repositori itu. Anda memperbarui copy pekerjaan Anda melalui pembaruan, dan Anda memperbarui repositori melalui komit.
Dengan kontrol versi terdistribusi, Anda tidak memiliki snapshot, melainkan seluruh basis kode. Ingin melakukan perbedaan dengan versi lama 3 bulan? Tidak masalah, versi lama 3 bulan masih ada di komputer Anda. Ini tidak hanya berarti segala sesuatunya jauh lebih cepat, tetapi jika Anda terputus dari server pusat Anda, Anda masih dapat melakukan banyak operasi yang biasa Anda lakukan. Dengan kata lain, Anda tidak hanya memiliki snapshot dari revisi yang diberikan, tetapi seluruh basis kode.
Anda akan berpikir bahwa Git akan menghabiskan banyak ruang pada harddisk Anda, tetapi dari beberapa tolok ukur yang saya lihat, sebenarnya dibutuhkan waktu lebih sedikit. Jangan tanya saya bagaimana. Maksudku, itu dibangun oleh Linus, dia tahu satu atau dua hal tentang sistem file, kurasa.
Poin utama yang saya sukai tentang DVCS adalah:
Alasan utama untuk proyek yang relatif besar adalah peningkatan komunikasi yang diciptakan oleh poin 3. Lainnya adalah bonus yang bagus.
Lucunya, saya meng-host proyek di Subversion Repos, tetapi mengaksesnya melalui perintah Git Clone.
Silakan baca Pengembangan dengan Git di Proyek Google Code
Meskipun Google Code secara alami berbicara Subversion, Anda dapat dengan mudah menggunakan Git selama pengembangan. Mencari "git svn" menunjukkan praktik ini tersebar luas, dan kami juga mendorong Anda untuk bereksperimen dengannya.
Menggunakan Git di Repositori Svn memberi saya manfaat:
backup/public untuk diperiksa orang lainSemua jawaban di sini seperti yang diharapkan, programmer sentris, namun apa yang terjadi jika perusahaan Anda menggunakan kontrol revisi di luar kode sumber? Ada banyak dokumen yang bukan kode sumber yang mendapat manfaat dari kontrol versi, dan harus hidup dekat dengan kode dan bukan di CMS lain. Sebagian besar programmer tidak bekerja secara terpisah - kami bekerja untuk perusahaan sebagai bagian dari tim.
Dengan mempertimbangkan hal itu, bandingkan kemudahan penggunaan, baik dalam tooling klien dan pelatihan, antara Subversion dan git. Saya tidak bisa melihat skenario di mana pun sistem terdistribusi kontrol revisi akan menjadi lebih mudah untuk menggunakan atau menjelaskan kepada non-programmer. Saya ingin terbukti salah, karena dengan begitu saya bisa mengevaluasi git dan benar-benar berharap itu diterima oleh orang-orang yang membutuhkan kontrol versi yang bukan programmer.
Meskipun begitu, jika ditanya oleh manajemen mengapa kita harus beralih dari sistem kontrol revisi yang tersentralisasi ke terdistribusi, saya akan sulit sekali memberikan jawaban yang jujur, karena kita tidak membutuhkannya.
Penafian: Saya menjadi tertarik pada Subversion sejak awal (sekitar v0.29) jadi jelas saya bias, tetapi perusahaan tempat saya bekerja sejak saat itu mendapat manfaat dari antusiasme saya karena saya telah mendorong dan mendukung penggunaannya. Saya menduga inilah yang terjadi pada sebagian besar perusahaan perangkat lunak. Dengan begitu banyak programmer melompat pada git ikut-ikutan, saya bertanya-tanya berapa banyak perusahaan akan kehilangan manfaat dari menggunakan kontrol versi di luar kode sumber? Bahkan jika Anda memiliki sistem terpisah untuk tim yang berbeda, Anda kehilangan beberapa manfaat, seperti integrasi pelacakan masalah (terpadu), sambil meningkatkan pemeliharaan, perangkat keras, dan persyaratan pelatihan.
Subversion masih merupakan sistem kontrol versi yang lebih banyak digunakan, yang berarti bahwa ia memiliki dukungan alat yang lebih baik. Anda akan menemukan plugin SVN matang untuk hampir semua IDE , dan ada ekstensi explorer yang baik tersedia (seperti TurtoiseSVN). Selain itu, saya harus setuju dengan Michael : Git tidak lebih baik atau lebih buruk daripada Subversion, itu berbeda.
Salah satu hal tentang SubVersion yang mengganggu saya adalah bahwa ia menempatkan foldernya sendiri di setiap direktori proyek, sedangkan git hanya menempatkan satu di direktori root. Ini bukan yang besar dari kesepakatan, tetapi hal-hal kecil seperti itu menambahkan.
Tentu saja, Subversi memiliki Kura-kura, yang [biasanya] sangat bagus.
David Richards WANdisco Blog tentang Subversion / GIT
Munculnya GIT telah membawa generasi fundamentalis DVCS - 'Gitterons' - yang berpikir bahwa selain GIT adalah omong kosong. Gitteron tampaknya berpikir rekayasa perangkat lunak terjadi di pulau mereka sendiri dan sering lupa bahwa sebagian besar organisasi tidak mempekerjakan insinyur perangkat lunak senior secara eksklusif. Tidak apa-apa tapi itu tidak seperti yang dipikirkan oleh sisa pasar, dan saya senang membuktikannya: GIT, pada tampilan terakhir memiliki kurang dari tiga persen pasar sementara Subversion memiliki di wilayah lima juta pengguna dan sekitar setengah dari pasar keseluruhan.
Masalah yang kami lihat adalah bahwa para Gitteron menembakkan tembakan (murah) ke Subversion. Tweets seperti “Subversion sangat [lambat / jelek / ketat / tidak berbau / menatapku dengan cara yang lucu] dan sekarang saya punya GIT dan [semuanya bekerja dalam hidup saya / istri saya hamil / saya punya pacar setelah 30 tahun mencoba / saya menang enam kali berlari di meja blackjack]. Anda mendapatkan fotonya.
Git juga membuat percabangan dan penggabungan sangat mudah. Subversion 1.5 baru saja menambahkan pelacakan gabungan, tetapi Git masih lebih baik. Dengan bercabang Git sangat cepat dan murah. Itu membuat membuat cabang untuk setiap fitur baru lebih layak. Repositori Oh dan Git sangat efisien dengan ruang penyimpanan dibandingkan dengan Subversion.
Ini semua tentang kemudahan penggunaan / langkah-langkah yang diperlukan untuk melakukan sesuatu.
Jika saya sedang mengembangkan satu proyek pada PC / laptop saya, git lebih baik, karena jauh lebih mudah untuk diatur dan digunakan. Anda tidak memerlukan server, dan Anda tidak perlu terus mengetik URL repositori ketika Anda melakukan penggabungan.
Jika hanya 2 orang, saya akan mengatakan git juga lebih mudah, karena Anda hanya bisa mendorong dan menarik dari satu sama lain.
Setelah Anda melampaui itu, saya akan melakukan subversi, karena pada saat itu Anda perlu mengatur server atau lokasi 'khusus'.
Anda dapat melakukan ini sama baiknya dengan git seperti halnya dengan SVN, tetapi manfaat dari git lebih besar daripada kebutuhan untuk melakukan langkah-langkah tambahan untuk menyinkronkan dengan server pusat. Di SVN Anda hanya melakukan. Di git Anda harus git komit, lalu git push. Langkah tambahan menjadi menjengkelkan hanya karena Anda akhirnya melakukannya begitu banyak.
SVN juga memiliki manfaat alat GUI yang lebih baik, namun ekosistem git sepertinya akan menyusul dengan cepat, jadi saya tidak akan khawatir tentang ini dalam jangka panjang.
Easy Git memiliki halaman yang bagus membandingkan penggunaan aktual Git dan SVN yang akan memberi Anda gambaran tentang hal-hal yang dapat dilakukan Git (atau melakukan lebih mudah) dibandingkan dengan SVN. (Secara teknis, ini didasarkan pada Easy Git, yang merupakan pembungkus ringan di atas Git.)
Git dan DVCS secara umum bagus untuk pengembang yang melakukan banyak pengkodean secara independen satu sama lain karena setiap orang memiliki cabang sendiri. Namun, jika Anda memerlukan perubahan dari orang lain, ia harus berkomitmen pada repo lokalnya dan kemudian ia harus mendorong perubahan itu kepada Anda atau Anda harus menariknya darinya.
Alasan saya sendiri juga membuat saya berpikir DVCS membuat segalanya lebih sulit untuk QA dan manajemen rilis jika Anda melakukan hal-hal seperti rilis terpusat. Seseorang harus bertanggung jawab untuk melakukan push / pull dari repositori orang lain, menyelesaikan setiap konflik yang akan diselesaikan pada waktu komit awal sebelumnya, kemudian melakukan build, dan kemudian membuat semua pengembang lain menyinkronkan ulang repo mereka.
Semua ini dapat diatasi dengan proses manusia, tentu saja; DVCS baru saja memecahkan sesuatu yang diperbaiki oleh kontrol versi terpusat untuk memberikan beberapa kenyamanan baru.
Saya suka Git karena sebenarnya membantu pengembang komunikasi untuk pengembang pada tim menengah ke besar. Sebagai sistem kontrol versi terdistribusi, melalui sistem dorong / tariknya, ini membantu pengembang untuk membuat sistem kode sumber yang membantu mengelola kumpulan besar pengembang yang mengerjakan satu proyek.
Misalnya, Anda mempercayai 5 pengembang dan hanya menarik kode dari repositori mereka. Masing-masing pengembang memiliki jaringan kepercayaan mereka sendiri dari mana mereka menarik kode. Dengan demikian pengembangan didasarkan pada jalinan kepercayaan pengembang di mana tanggung jawab kode dibagi di antara komunitas pengembangan.
Tentu saja ada manfaat lain yang disebutkan dalam jawaban lain di sini.
Beberapa jawaban telah menyinggung ini, tetapi saya ingin membuat 2 poin eksplisit:
1) Kemampuan untuk melakukan komitmen selektif (misalnya, git add --patch). Jika direktori kerja Anda berisi beberapa perubahan yang bukan bagian dari perubahan logis yang sama, Git membuatnya sangat mudah untuk membuat komit yang hanya mencakup sebagian dari perubahan. Dengan Subversion, itu sulit.
2) Kemampuan untuk berkomitmen tanpa membuat perubahan publik. Dalam Subversion, komit apa pun segera publik, dan karenanya tidak dapat dibatalkan. Ini sangat membatasi kemampuan pengembang untuk "melakukan lebih awal, melakukan sering".
Git lebih dari sekedar VCS; itu juga alat untuk mengembangkan tambalan. Subversi hanyalah sebuah VCS.
Saya pikir Subversion baik-baik saja .. sampai Anda mulai menggabungkan .. atau melakukan sesuatu yang rumit .. atau melakukan apa pun yang menurut Subversion rumit (seperti melakukan pertanyaan untuk mencari tahu cabang mana yang kacau dengan file tertentu, di mana perubahan sebenarnya berasal, mendeteksi copy & paste , dll) ...
Saya tidak setuju dengan jawaban yang menang, mengatakan bahwa manfaat utama GIT adalah pekerjaan offline - ini tentu berguna, tetapi lebih seperti tambahan untuk kasus penggunaan saya. SVK dapat bekerja secara offline juga, masih tidak ada pertanyaan bagi saya yang menginvestasikan waktu belajar saya).
Hanya saja itu sangat kuat dan cepat dan, setelah terbiasa dengan konsep - sangat berguna (ya, dalam arti: ramah pengguna).
Untuk detail lebih lanjut tentang kisah penggabungan, lihat ini: Menggunakan git-svn (atau serupa) * hanya * untuk membantu penggabungan svn?
Berkat fakta itu tidak perlu berkomunikasi dengan server pusat terus-menerus, cukup banyak setiap perintah berjalan dalam waktu kurang dari satu detik (jelas git push / pull / fetch lebih lambat hanya karena mereka harus menginfeksi koneksi SSH). Bercabang jauh lebih mudah (satu perintah sederhana untuk bercabang, satu perintah sederhana untuk digabung)
Saya benar-benar senang bisa mengelola cabang-cabang lokal dari kode sumber saya di Git tanpa mengeruhkan air repositori pusat. Dalam banyak kasus, saya akan checkout kode dari server Subversion dan menjalankan repositori Git lokal hanya untuk dapat melakukan ini. Sangat bagus juga bahwa menginisialisasi repositori Git tidak mencemari sistem file dengan banyak folder .svn yang mengganggu di mana-mana.
Dan sejauh dukungan alat Windows, TortoiseGit menangani dasar-dasarnya dengan sangat baik, tapi saya masih lebih suka baris perintah kecuali saya ingin melihat log. Saya sangat suka cara Tortoise {Git | SVN} membantu ketika membaca log komit.
Ini adalah pertanyaan yang salah untuk ditanyakan. Terlalu mudah untuk berfokus pada kutil git dan merumuskan argumen tentang mengapa subversi tampak lebih baik, setidaknya untuk beberapa kasus penggunaan. Fakta bahwa git pada awalnya dirancang sebagai set konstruksi kontrol versi tingkat rendah dan memiliki antarmuka berorientasi-pengembang baroque linux memudahkan perang suci untuk mendapatkan traksi dan legitimasi yang dirasakan. Pendukung Git menggedor drum dengan jutaan keuntungan alur kerja, yang oleh semua orang dinyatakan tidak perlu. Segera seluruh perdebatan dibingkai sebagai terpusat vs terdistribusi, yang melayani kepentingan komunitas alat svn perusahaan. Perusahaan-perusahaan ini, yang biasanya mengeluarkan artikel paling meyakinkan tentang keunggulan subversi di perusahaan,
Tapi inilah masalahnya: Subversi adalah jalan buntu arsitektur .
Sedangkan Anda dapat mengambil git dan membangun penggantian subversi terpusat dengan cukup mudah, meskipun sudah ada lebih dari dua kali lipat svn tidak pernah bisa mendapatkan bahkan pelacakan penggabungan dasar yang bekerja di dekat maupun git. Salah satu alasan dasar untuk ini adalah keputusan desain untuk membuat cabang sama dengan direktori. Saya tidak tahu mengapa mereka pergi dengan cara ini pada awalnya, itu tentu saja membuat pembayaran sebagian sangat sederhana. Sayangnya itu juga membuat tidak mungkin untuk melacak sejarah dengan benar. Sekarang jelas Anda seharusnya menggunakan konvensi tata letak repositori subversi untuk memisahkan cabang dari direktori biasa, dan svn menggunakan beberapa heuristik untuk membuat sesuatu berfungsi untuk kasing harian. Tetapi semua ini hanya menutupi keputusan desain tingkat rendah yang sangat buruk dan terbatas. Mampu melakukan diff repositori-bijaksana (daripada diff direktori-bijaksana) adalah fungsi dasar dan kritis untuk sistem kontrol versi, dan sangat menyederhanakan internal, sehingga memungkinkan untuk membangun fitur yang lebih cerdas dan berguna di atasnya. Anda dapat melihat dalam jumlah upaya yang telah dilakukan untuk memperluas subversi, namun seberapa jauh di balik itu dari tanaman VCS modern saat ini dalam hal operasi mendasar seperti resolusi gabungan.
Sekarang, inilah saran saya yang menyentuh hati dan agnostik bagi siapa pun yang masih percaya bahwa Subversion cukup baik untuk masa mendatang:
Subversion tidak akan pernah mengejar keturunan VCSes yang lebih baru yang telah belajar dari kesalahan RCS dan CVS; itu adalah ketidakmungkinan teknis kecuali mereka memperlengkapi kembali model repositori dari bawah ke atas, tetapi kemudian tidak akan benar-benar menjadi svn bukan? Terlepas dari seberapa banyak Anda berpikir Anda tidak memiliki kemampuan VCS modern, ketidaktahuan Anda tidak akan melindungi Anda dari jebakan Subversion, banyak di antaranya adalah situasi yang tidak mungkin atau mudah diselesaikan dalam sistem lain.
Sangat jarang bahwa inferioritas teknis dari suatu solusi begitu jelas seperti halnya dengan svn, tentu saja saya tidak akan pernah menyatakan pendapat seperti itu tentang win-vs-linux atau emacs-vs-vi, tetapi dalam hal ini sangat tebang habis, dan kontrol sumber adalah alat mendasar dalam arsenal pengembang, sehingga saya merasa harus dinyatakan dengan tegas. Terlepas dari persyaratan untuk menggunakan svn untuk alasan organisasi, saya mohon semua pengguna svn untuk tidak membiarkan pikiran logis mereka membangun kepercayaan yang salah bahwa VCS yang lebih modern hanya berguna untuk proyek-proyek open-source besar. Terlepas dari sifat pekerjaan pengembangan Anda, jika Anda seorang programmer, Anda akan menjadi programmer yang lebih efektif jika Anda belajar cara menggunakan VCSes yang dirancang lebih baik, apakah itu Git, Mercurial, Darcs, atau banyak lainnya.
Subversi sangat mudah digunakan. Saya tidak pernah menemukan masalah dalam tahun-tahun terakhir ini atau ada sesuatu yang tidak berfungsi seperti yang diharapkan. Juga ada banyak alat GUI yang sangat baik dan dukungan untuk integrasi SVN besar.
Dengan Git Anda mendapatkan VCS yang lebih fleksibel. Anda bisa menggunakannya dengan cara yang sama seperti SVN dengan repositori jarak jauh di mana Anda melakukan semua perubahan. Tetapi Anda juga dapat menggunakannya sebagian besar offline dan hanya mendorong perubahan dari waktu ke waktu ke repositori jarak jauh. Tetapi Git lebih kompleks dan memiliki kurva belajar yang lebih curam. Saya menemukan diri saya pertama kali berkomitmen ke cabang yang salah, membuat cabang secara tidak langsung atau mendapatkan pesan kesalahan dengan tidak banyak informasi tentang kesalahan dan di mana saya harus mencari dengan Google untuk mendapatkan informasi yang lebih baik. Beberapa hal mudah seperti penggantian marker ($ Id $) tidak berfungsi tetapi GIT memiliki mekanisme penyaringan dan pengait yang sangat fleksibel untuk menggabungkan skrip sendiri dan sehingga Anda mendapatkan semua hal yang Anda butuhkan dan lebih banyak tetapi membutuhkan lebih banyak waktu dan membaca dokumentasi. ;)
Jika Anda sebagian besar bekerja offline dengan repositori lokal Anda, Anda tidak memiliki cadangan jika ada sesuatu yang hilang pada mesin lokal Anda. Dengan SVN Anda sebagian besar bekerja dengan repositori jarak jauh yang juga merupakan waktu yang sama dengan cadangan Anda di server lain ... Git dapat bekerja dengan cara yang sama tetapi ini bukan tujuan utama Linus untuk memiliki sesuatu seperti SVN2. Itu dirancang untuk pengembang kernel Linux dan kebutuhan sistem kontrol versi terdistribusi.
Apakah Git lebih baik daripada SVN? Pengembang yang hanya membutuhkan beberapa riwayat versi dan mekanisme cadangan memiliki kehidupan yang baik dan mudah dengan SVN. Pengembang sering bekerja dengan cabang, menguji lebih banyak versi pada saat yang sama atau bekerja sebagian besar offline dapat mengambil manfaat dari fitur Git. Ada beberapa fitur yang sangat berguna seperti menyimpan tidak ditemukan dengan SVN yang dapat membuat hidup lebih mudah. Tetapi di sisi lain tidak semua orang akan membutuhkan semua fitur. Jadi saya tidak bisa melihat kematian SVN.
Git membutuhkan dokumentasi yang lebih baik dan pelaporan kesalahan harus lebih bermanfaat. Juga GUI berguna yang ada jarang. Kali ini saya hanya menemukan 1 GUI untuk Linux dengan dukungan sebagian besar fitur Git (git-cola). Integrasi Eclipse berfungsi tetapi tidak resmi dirilis dan tidak ada situs pembaruan resmi (hanya beberapa situs pembaruan eksternal dengan versi berkala dari trunk http://www.jgit.org/updates ) Jadi cara yang paling disukai untuk menggunakan Git hari ini adalah baris perintah.
Eric Sink dari SourceGear menulis serangkaian artikel tentang perbedaan antara sistem kontrol versi terdistribusi dan tidak terdistribusi. Dia membandingkan pro dan kontra dari sistem kontrol versi paling populer. Bacaan yang sangat menarik.
Artikel dapat ditemukan di blog-nya, www.ericsink.com :
Bagi orang yang mencari Git GUI yang baik, Syntevo SmartGit mungkin menjadi solusi yang baik. Hak miliknya, tetapi gratis untuk penggunaan non-komersial, berjalan pada Windows / Mac / Linux dan bahkan mendukung SVN menggunakan semacam jembatan git-svn, saya pikir.
http://subversion.wandisco.com/component/content/article/1/40.html
Saya pikir cukup aman untuk mengatakan bahwa di antara pengembang, SVN Vs. Argumen Git telah berkobar selama beberapa waktu sekarang, dengan setiap orang memiliki pandangan mereka sendiri tentang mana yang lebih baik. Ini bahkan dimunculkan dalam pertanyaan-pertanyaan selama Webinar kami tentang Subversion pada tahun 2010 dan Selanjutnya.
Hyrum Wright, Direktur Open Source kami dan Presiden untuk Subversion Corporation berbicara tentang perbedaan antara Subversion dan Git, bersama dengan Sistem Kontrol Versi Terdistribusi (DVCS) lainnya.
Dia juga berbicara tentang perubahan yang akan datang dalam Subversion, seperti Working Copy Next Generation (WC-NG), yang dia yakini akan menyebabkan sejumlah pengguna Git kembali ke Subversion.
Tonton videonya dan beri tahu kami apa yang Anda pikirkan dengan berkomentar di blog ini, atau dengan memposting di forum kami. Pendaftarannya sederhana dan hanya perlu waktu sebentar!
Git di Windows didukung dengan cukup baik sekarang.
Lihat GitExtensions = http://code.google.com/p/gitextensions/
dan manual untuk pengalaman Windows Git yang lebih baik.
Saya telah tinggal di tanah Git akhir-akhir ini, dan saya menyukainya untuk proyek-proyek pribadi, tetapi saya belum dapat mengalihkan proyek-proyek pekerjaan ke sana dari Subversion mengingat perubahan pemikiran yang diperlukan dari staf, tanpa ada manfaat yang mendesak. Selain itu, proyek terbesar yang kami jalankan di rumah sangat tergantung pada svn: eksternal yang, dari apa yang saya lihat sejauh ini, tidak bekerja dengan baik dan mulus di Git.
Pertama, kontrol versi bersamaan sepertinya merupakan masalah yang mudah dipecahkan. Sama sekali tidak. Bagaimanapun...
SVN cukup non-intuitif. Git bahkan lebih buruk. [sarkastik-spekulasi] Ini mungkin karena pengembang, yang suka masalah sulit seperti kontrol versi bersamaan, tidak memiliki banyak minat dalam membuat UI yang bagus. [/ spekulasi sarkastik]
Pendukung SVN berpikir mereka tidak membutuhkan sistem kontrol versi terdistribusi. Saya juga memikirkan itu. Tapi sekarang kita menggunakan Git secara eksklusif, saya seorang yang beriman. Sekarang kontrol versi berfungsi untuk saya DAN tim / proyek alih-alih hanya bekerja untuk proyek. Ketika saya membutuhkan cabang, saya bercabang. Kadang-kadang itu adalah cabang yang memiliki cabang yang sesuai di server, dan kadang-kadang tidak. Belum lagi semua keuntungan lain yang harus saya pelajari (sebagian berkat UI yang absurd dan absurd yang merupakan sistem kontrol versi modern).
Mengapa saya berpikir Subversion lebih baik daripada Git (setidaknya untuk proyek yang saya kerjakan), terutama karena kegunaannya, dan alur kerja yang lebih sederhana:
http://www.databasesandlife.com/why-subversion-is-better-than-git/