Apa yang dilakukan SVN lebih baik daripada Git? [Tutup]


293

Tidak ada pertanyaan bahwa sebagian besar perdebatan tentang alat programmer menyaring pilihan pribadi (oleh pengguna) atau penekanan desain , yaitu , mengoptimalkan desain sesuai dengan kasus penggunaan tertentu (oleh pembuat alat). Editor teks mungkin adalah contoh yang paling menonjol - seorang pembuat kode yang bekerja pada Windows di kantor dan kode di Haskell pada Mac di rumah, menghargai cross-platform dan integrasi kompiler dan memilih Emacs di atas TextMate , dll.

Itu kurang umum bahwa teknologi yang baru diperkenalkan benar-benar, terbukti lebih unggul dari pilihan yang ada.

Apakah ini sebenarnya kasus dengan sistem kontrol versi (VCS), khususnya, VCS terpusat ( CVS dan SVN ) dibandingkan VCS terdistribusi ( Git dan Mercurial )?

Saya menggunakan SVN selama sekitar lima tahun, dan SVN saat ini digunakan di tempat saya bekerja. Kurang dari tiga tahun yang lalu, saya beralih ke Git (dan GitHub) untuk semua proyek pribadi saya.

Saya dapat memikirkan sejumlah keunggulan Git daripada Subversion (dan yang sebagian besar abstrak untuk keuntungan didistribusikan melalui VCS tersentralisasi), tetapi saya tidak dapat memikirkan satu contoh contra - beberapa tugas (yang relevan dan muncul di programer biasa) alur kerja) bahwa Subversion lebih baik daripada Git.

Satu- satunya kesimpulan yang saya ambil dari ini adalah bahwa saya tidak memiliki data - bukan bahwa Git lebih baik, dll.

Dugaan saya adalah bahwa contoh tandingan semacam itu ada, maka dari itu pertanyaan ini.


3
@jokoon: Efisien dalam hal apa? Tentunya tidak cepat karena bahkan Ethernet cepat pun lambat dibandingkan dengan operasi lokal.
maaartinus


4
Saya selalu berpikir Git sangat dihargai. Ini adalah mode, dan programmer tidak tahan terhadap mode - terlepas dari banyak oposisi terhadap pemikiran ini. Seperti semua orang di dunia ini, semua orang menginginkan mainan baru yang mengkilap (Git). Git mungkin baik - atau bahkan hebat bagi sebagian orang - tetapi itu tidak pernah lebih baik dari SVN ketika berpikir secara objektif.
dibeli 777

3
Saya pikir SVN masih bagus untuk digunakan, kurva belajarnya bagus kemudian GIT.
Cheung

5
Pertanyaan ini baru-baru ini ditunda karena sebagian besar didasarkan pada pendapat. Klasifikasi itu salah; perhatikan bahwa pertanyaan itu terbuka untuk waktu yang lama; bahwa ada banyak pertanyaan tentang kebajikan DVCS, dan bahwa pertanyaan itu tidak menanyakan apakah itu lebih baik (pendapat), tetapi apa yang dilakukannya lebih baik. Perbedaannya bukan pendapat tetapi apakah keseluruhan produk - itu rumit (tetapi bukan inti dari pertanyaan ini).
Eamon Nerbonne

Jawaban:


207

Subversi adalah repositori pusat

Sementara banyak orang ingin membagikan repositori untuk manfaat nyata dari kecepatan dan banyak salinan, ada beberapa situasi di mana repositori pusat lebih diinginkan. Misalnya, jika Anda memiliki kode penting yang tidak ingin diakses siapa pun, Anda mungkin tidak ingin meletakkannya di bawah Git. Banyak perusahaan ingin menjaga kode mereka terpusat, dan (saya kira) semua proyek pemerintah (serius) berada di bawah repositori pusat.

Subversi adalah kebijaksanaan konvensional

Ini untuk mengatakan bahwa banyak orang (terutama manajer dan bos) memiliki cara yang biasa untuk memberi nomor versi dan melihat pengembangan sebagai "baris tunggal" sepanjang waktu dimasukkan ke dalam otak mereka. Jangan tersinggung, tetapi kebebasan Git tidak mudah ditelan. Bab pertama dari setiap buku Git memberitahu Anda untuk mengosongkan semua cita-cita konvensional dari pikiran Anda dan mulai lagi.

Subversi melakukannya dengan satu cara, dan tidak ada yang lain

SVN adalah sistem kontrol versi. Ia memiliki satu cara untuk melakukan tugasnya dan semua orang melakukannya dengan cara yang sama. Titik. Ini memudahkan transisi ke / dari SVN dari / ke VCS terpusat lainnya. Git bahkan BUKAN VCS murni - ini adalah sistem file, memiliki banyak topologi untuk cara mengatur repositori dalam situasi yang berbeda - dan tidak ada standar. Itu membuatnya lebih sulit untuk memilih satu.

Keuntungan lain adalah:

  • SVN mendukung direktori kosong
  • SVN memiliki dukungan Windows yang lebih baik
  • SVN dapat memeriksa / mengkloning sub-pohon
  • SVN mendukung kontrol akses eksklusif svn lockyang berguna untuk file yang sulit digabungkan
  • SVN mendukung file biner dan file besar lebih mudah (dan tidak perlu menyalin versi lama di mana-mana).
  • Menambahkan komit melibatkan langkah-langkah yang jauh lebih sedikit karena tidak ada tarikan / dorongan dan perubahan lokal Anda selalu secara implisit diubah svn update.

55
"Subversi melakukannya dalam satu cara" - Saya juga berpikir demikian, sampai saya memulai pekerjaan saya saat ini. Dalam pekerjaan saya saat ini, bos saya, yang mengaku tidak memiliki masalah kepercayaan, mengkonfigurasi server untuk meminta penguncian. Tidak ada penggabungan yang terjadi di sistem kami. File dikunci di repositori dan tidak ada orang lain yang dapat menulisnya tanpa kunci. Kontrol top-down, bagi mereka yang konstitusi menuntutnya, jelas merupakan sesuatu yang dilakukan svn lebih baik daripada git.
Dan Ray

14
Salah satu keuntungan dari repositori pusat adalah kemudahan cadangan. Jika semua kode yang diperiksa ada di satu tempat, dan satu tempat itu memiliki cadangan di luar lokasi, Anda tidak akan kehilangan segalanya jika kantor Anda terbakar. Dengan DVCS, kecuali jika Anda melakukan pencadangan di luar situs dari mesin pengembang, Anda kehilangan semua yang belum didorong ke server yang dicadangkan di luar situs.
Paul Tomblin

94
Mengapa git tidak bisa digunakan secara terpusat? Hanya memiliki satu repositori pusat, dan devs Anda dapat mengkloning dan menarik dan mendorong seperti mereka checkout dan memperbarui dan melakukan.
David Thornley

29
@ PaulTomblin - Bergantung pada alur kerja, Git dapat memberikan cadangan yang lebih baik . Sebagai contoh, kami menggunakan repositori github pribadi dan saya sering mendorong kode saya ke cabang fitur. Jika rekan kerja saya melakukannya git fetch origin, masing-masing dari mereka memiliki cadangan kode saya, bersama dengan cadangan apa pun yang disediakan Github sendiri. (Kami secara teratur memangkas cabang-cabang yang digabungkan, baik secara lokal maupun di Github.)
Nathan Long

52
Anda tampaknya menyiratkan bahwa pusat lebih aman untuk perusahaan besar atau pekerjaan pemerintah. Ini tidak benar. Jika Anda memiliki salinan kode di komputer Anda, Anda memiliki salinan kode tersebut. Tidak masalah jika itu berasal dari server pusat atau sistem file pusat yang memegang repositori DVCS.
John Fisher

131

Salah satu manfaat dari Subversion lebih Git dapat menjadi yang Subversion memungkinkan memeriksa sub-pohon saja. Dengan Git seluruh repositori adalah sebuah unit, Anda hanya bisa mendapatkan semua atau tidak sama sekali. Dengan kode modular, ini bisa sangat bagus dibandingkan dengan submodules Git. (Sementara submitula Git juga mendapatkan tempatnya, jelas.)

Dan sedikit manfaat kecil: Subversi dapat melacak direktori kosong. Git melacak konten file, sehingga direktori tanpa file apa pun tidak akan muncul.


11
Bekerja dengan sub pohon adalah IMHO, satu-satunya hal yang dimiliki SVN atas GIT. Poin yang diambil, direktori kosong itu bagus, tetapi juga tidak perlu (dan dapat dikerjakan). Jika submitules git dan subtit git kurang membingungkan, tidak akan ada yang menahan banyak orang untuk bermigrasi ke GIT. Yang lain keuntungan beberapa orang yang disebutkan mendidih ke (pengembang) mentalitas. Misalnya jika Anda perlu dari atas ke bawah, itu tidak masalah. Saya tidak akan memiliki pekerjaan untuk Anda sekalipun.
Hingga

3
Sangat lucu bagaimana ini adalah satu-satunya hal yang dapat diperdebatkan dalam mendukung SVN (dan kontrol versi terpusat lainnya)
dukeofgaming

1
Kenapa itu lucu? - Sistem yang lebih baru belajar dari sistem yang lebih lama. Bahkan ada manfaat dengan RCS lebih dari git: File riwayat dapat dengan mudah diedit dengan tangan dan Anda dapat memiliki cabang per-file. Tetapi eolution melibatkan fitur yang hilang ...
johannes

3
Saya mendengar tentang sebuah perusahaan game yang menggunakan SVN over GIT untuk alasan ini - ketika Anda berbicara tentang repositori dengan banyak GB, tiba-tiba menjadi penting!
James

18
Pada git versi 1.8.0, Anda sekarang dapat menggunakan git subtreeperintah untuk menyelesaikannya dengan tepat. Keuntungan subversi terakhir menggigit debu :) Detail di sini: github.com/gitster/git/blob/... Catatan: Meskipun ini adalah tautan ke proyek github, git-subtree sekarang menjadi bagian dari distribusi inti git.
Carl

51

Saya bisa memikirkan tiga. Pertama, ini sedikit lebih mudah untuk grok, terutama untuk yang bukan pengembang. Secara konseptual, ini jauh lebih sederhana daripada opsi DCVS . Yang kedua adalah kematangan, khususnya TortoiseSVN di Windows. TortoiseHg mengejar ketinggalan dengan cepat. Ketiga, sifat binatang - hanya gambar dari sistem file tempat Anda dapat memeriksa berbagai hal dari tingkatan pohon - dapat berguna dalam beberapa skenario - seperti membuat versi berbagai file konfigurasi yang sangat berbeda di puluhan server tanpa puluhan repositori.

Ini bukan untuk mengatakan kami tidak memindahkan semua pengembangan ke Mercurial.


25
Menjadi lebih mudah untuk grok adalah keuntungan penting, karena itu membuatnya lebih mungkin untuk digunakan. SVN tentu jauh lebih baik daripada tidak ada kontrol versi, dan jika seseorang keras kepala tentang cara lama maka mungkin SVN adalah pilihan terbaik bagi mereka.
jhocking

12
@jhocking: Saya tidak suka SVN, tetapi jika seseorang mengatakan kepada saya "Saya tidak suka hal-hal DVCS baru ini, jadi saya akan tetap dengan CVS", maka saya pasti akan merekomendasikannya: ini adalah jalan paling mudah untuk setidaknya VCS sebagian waras ;-)
Joachim Sauer

4
@jhocking Cara baru tidak selalu yang terbaik untuk setiap keadaan. Ini mengingatkan cerita lama tentang NASA yang menghabiskan jutaan dolar untuk mengembangkan pena yang dapat menulis dalam 0g. Kosmonot di sisi lain dibuat dengan pensil. Terkadang cara lama lebih baik, SEKARANG MEMBUAT HUKUM SAYA!
maple_shaft

25
@maple_shaft, dan terkadang tidak. snopes.com/business/genius/spacepen.asp
Peter Taylor

3
Mudah grokked sangat subyektif, dan sebagian besar didasarkan pada bagaimana Anda mencoba menyesuaikan pengetahuan baru dengan apa yang sudah Anda ketahui. Ini juga membuat banyak perbedaan apa sumber belajar Anda. Jika Anda membaca halaman manual, semoga berhasil. Jika Anda diajar oleh guru yang baik yang sudah menggerutu, Anda sudah mendapatkannya. Saya menemukan git masuk akal setelah menonton beberapa video bagus di YouTube. Jika Anda mendapatkan pemahaman dari seseorang yang telah menyaringnya hingga ke inti sederhana, maka segala sesuatu lebih mudah untuk dipahami.
WarrenT

32
  • Gudang SVN lebih mudah dikelola dari sudut pandang manajer dan administrator ( metode otentikasi ACL + + hotcopy + mirror + dumps)
  • SVN * -hooks lebih mudah diimplementasikan dan didukung
  • svn:external memiliki kekuatan dan fleksibilitas lebih dari submodula
  • Pohon repositori berbasis filesystem lebih mudah digunakan daripada repositori monolitik dengan pemisahan hanya-logis
  • SVN memiliki lebih banyak alat klien yang berbeda
  • SVN memiliki antarmuka web yang dapat digunakan pihak ketiga, jauh lebih baik daripada Git
  • SVN tidak merusak otak Anda

23
Tidak merusak otakmu? Ingin mengajari saya cara mudah menggabungkan cabang dengan konflik di SVN?
WarrenT

4
Alat / ujung depan yang lebih baik, itu adalah target yang bergerak. Alat meningkatkan di kedua sisi. Tak satu pun dari kita yang tahu alat apa yang akan tersedia beberapa tahun dari sekarang. Penilaian itu 10 bulan lalu mungkin dengan mudah berubah dari waktu ke waktu, dan mungkin basi sekarang. Saya lebih suka melihat jawaban substantif.
WarrenT

6
Konflik pohon? Memeriksa. Ya atau tidak untuk semua opsi? Tidak. Svn dirancang untuk membuat marah. Bersihkan perintah salin yang berfungsi? Tidak. Kembalikan tidak dapat membersihkan file yang tidak berversi.
Warren P

1
Menghapus semuanya dan memeriksa lagi akan membersihkan file yang tidak berversi.
jgmjgm

Saya suka ide terakhir Anda, Git mematahkan otak saya: '(
Luke

24

Saya menulis ini sebagai komentar atas jawaban orang lain, tetapi saya rasa ini layak menjadi jawaban dalam dirinya sendiri.

Konfigurasi SVN perusahaan saya yang dipilih dengan cermat membutuhkan penguncian tingkat file untuk mengedit konten, dan tidak pernah menggunakan penggabungan. Akibatnya, banyak pengembang bersaing untuk mengunci, dan itu bisa menjadi hambatan besar, dan tidak pernah ada kemungkinan konflik gabungan.

SVN jelas melakukan kontrol manajerial top-down lebih baik daripada Git. Dalam migrasi skunkworks saya ke Git (meminta pengampunan alih-alih izin), saya berkali-kali menakuti manajer saya dengan anggapan bahwa tidak ada server utama yang mengendalikan server yang mengendalikan perangkat lunak tempat kita semua adalah budak.


Sentralitas adalah masalah mitos, bukan fakta. Tidak ada yang bisa menghentikan saya untuk mengubah apa pun. Dengan cvcs mereka dapat menghentikan saya dari mengubah sesuatu secara terpusat. Hal yang sama dalam DVD. Kata commit di cvcs mengonfigurasikan commit dan push.
Warren P

@ JonathanHenson: itu jelas bukan satu-satunya alasan Torvalds membenci SVN. SVN mungkin tersentralisasi dan mungkin CVS yang lebih baik tetapi itu tidak membuatnya menjadi perangkat lunak yang baik. Torvalds membenci CVS / SVN bukan karena mereka terpusat tetapi karena dia menganggap mereka perangkat lunak yang menyedihkan. Apakah dia benar atau tidak, itu terserah Anda untuk memutuskan tetapi melihat keberhasilan besar dari Linux (dan Android) - berjalan di miliaran perangkat - dan Git - yang cukup banyak membawa dunia oleh badai -, saya Aku berpikir dua kali sebelum tidak setuju dengannya. Ceramah yang diberikan Torvalds di Google pada Git tahun lalu sungguh menakjubkan.
Cedric Martin

lol. Manajer Anda merasa takut karena tidak ada sistem cadangan yang tepat. Hanya mengatakan "tetapi DVCS-nya sehingga seseorang akan memiliki salinan" tidak terbang - Saya tahu, ketika saya melihat git digunakan di tempat terakhir saya, mereka benar-benar tidak memiliki salinan dari beberapa repo. Ingat, penguncian bisa baik untuk beberapa situasi dan git gagal dalam hal ini - kecuali jika Anda memiliki alat penggabungan ajaib untuk gambar atau file biner lainnya. git hanya berfungsi untuk file teks.
gbjbaanb

22

Alasan saya:

  • jatuh tempo - baik server, dan alat-alatnya (mis. TortoiseSVN)
  • kesederhanaan - lebih sedikit langkah yang terlibat, komit adalah komitmen. DVCS seperti Git dan Mercurial melibatkan komit, lalu dorong.
  • penanganan biner - SVN menangani executable dan gambar biner lebih baik dari Git / Hg. Sangat berguna dengan proyek .NET karena saya ingin memeriksa alat yang terkait dengan bangunan ke dalam kontrol sumber.
  • penomoran - SVN memiliki skema penomoran komit yang dapat dibaca, menggunakan hanya angka - lebih mudah untuk melacak angka revisi. Git dan Hg melakukan ini dengan sangat berbeda.

1
"skema penomoran komit" hanya mungkin jika Anda memiliki batang kanonik. Kalau tidak, yang mana yang mendapat penomoran utama?

1
Memberi +1 angka di svn. Jumlah ini unik. ada alat untuk menggunakan nomor ini sebagai bagian dari app-versionnumber xx.yy.zz.12882 di mana 12882 adalah nomor versi svn. Jika ada masalah produksi, Anda dapat meminta nomor versi dan Anda memiliki revisi svn yang tepat di mana perangkat lunak itu dibuat
k3b

22

Saya menghargai bahwa Anda mencari informasi yang baik, tetapi pertanyaan semacam ini hanya mengundang, "Saya pikir Git sangat menang, dan svn teh suxorz!" jawaban.

Saya mencoba dan secara pribadi menemukan Git terlalu banyak untuk tim kecil saya. Sepertinya itu akan bagus untuk tim besar atau kelompok tim yang tersebar secara geografis. Saya sangat memahami manfaat Git, tetapi kontrol sumber menurut saya bukan sesuatu yang membuat saya terjaga di malam hari.

Saya adalah pemburu rusa, dan ketika saya dan teman-teman saya keluar mereka dipersenjatai dengan gigi, dipenuhi dengan amunisi dan peralatan teknologi tinggi. Saya muncul dengan senapan tunggal, tujuh peluru dan pisau buck. Jika saya membutuhkan lebih dari tujuh putaran maka saya melakukan sesuatu yang salah, dan saya juga melakukan hal yang sama.

Poin yang saya coba sampaikan adalah bahwa jika Anda adalah tim kecil yang mengerjakan proyek menengah ke kecil dan Anda sudah terbiasa dengan SVN maka gunakanlah. Ini tentu lebih baik daripada CVS atau (gemetar) SourceSafe , dan saya tidak perlu lebih dari lima menit untuk mengatur repositori. Git terkadang bisa berlebihan.


3
Benarkah? Maka saya sarankan Anda melihat fosil .
Spencer Rathbun

7
jangan membunyikan alarm pada kemungkinan kontroversi. Topik-topik penting sering kali paling kontroversial dan yang paling mungkin memunculkan pandangan yang kuat. Jadi, "Pertanyaan seperti ini" adalah penting dan kemungkinan respons di luar batas bukanlah masuk akal untuk tidak diposkan. Saya menganggap pengguna di Situs ini adalah orang dewasa. Terlebih lagi, bagaimana Q saya diungkapkan, jika tidak netral, maka hormat kepada orang-orang subversi - jawaban responsif terhadap Q saya harus melafalkan keuntungan dari subversi atas git, bukan sebaliknya.
doug

@SpencerRathbun, Terima kasih! Saya harus melihat itu. Bukan karena aku mencintai svn karena aku tidak menyukai git.
maple_shaft

10
@Spencer - Sebaliknya, sebagai pengguna keduanya gitdan hg, saya sarankan lincah bagi siapa saja yang berpikir gitterlalu banyak. TortoiseHG akan sangat akrab bagi siapa pun yang terbiasa dengan TortoiseSVN (bahkan berbagi overlay Explorer yang sama pada Windows). Ini tentu jauh lebih mudah daripada VSS dan saya akan terkejut jika butuh lebih dari beberapa detik untuk mengatur repo hg, komit keadaan awal dan mengkloningnya ke drive bersama.
Mark Booth

@ MarkBooth Seperti yang dinyatakan dalam pertanyaan awal, saya pikir ini masalah keinginan dan kebutuhan. Di tempat kerja saya saat ini, tidak ada repo sebelum saya sampai di sana. Saya membutuhkan sesuatu yang memiliki semua, atau sebagian besar, alat-alat proyek yang saya inginkan dibungkus bersama, mudah digunakan, menyimpan semuanya daripada delta, dan akan bekerja didistribusikan untuk tim 1 atau 2 orang di beberapa mesin.
Spencer Rathbun

20

Ini semua relatif, dan seperti yang dikatakan maple_shaft, jika ada yang cocok untuk Anda, jangan ubah!

Tetapi jika Anda benar-benar menginginkan sesuatu , saya akan mengatakan itu mungkin lebih baik untuk desainer, programmer web dan semacamnya - ini menangani gambar dan file biner sedikit lebih baik.


2
Bagaimana SVN menanganinya dengan lebih baik? Git menganggap setiap file sebagai gumpalan.
WarrenT

4
@ WarrenT karena alur kerja, dengan git Anda bercabang dan banyak menggabungkan (atau mengapa repot menggunakannya) dan Anda tidak bisa secara realistis menggabungkan biner. Karenanya, Anda sering meletakkan properti "needs lock" pada file biner di SVN.
gbjbaanb

1
Beberapa binari dapat (secara teoritis) digabung, misalnya, dokumen ODT.
Donal Fellows

18

Kegunaan. Ini bukan benar-benar pantas Subversion melainkan TortoiseSVN .. TortoiseGit ada, tetapi masih memiliki jalan panjang untuk mencocokkan TortoiseSVN.

Jika Anda bertanya apa yang dilakukan Git lebih baik dari SVN, saya akan membalas GitHub . Lucu bagaimana alat pihak ketiga membuat perbedaan besar.


1
Assembla (untuk SCM yang didukung - SVN dalam daftar) lebih baik daripada github, saya pikir
Lazy Badger

ada juga smartgit, GitXL, dll. sekarang, program yang membuat penggunaan git menjadi lebih sederhana
wirrbel

@ LazyBadger, Belum pernah mendengarnya.
Pacerier

16

Ketika Anda tidak perlu melakukan percabangan dan penggabungan , SVN (dengan TortoiseSVN di Windows) sangat mudah dipahami dan digunakan. Git terlalu rumit untuk kasus-kasus sederhana, karena ia mencoba membuat percabangan / penggabungan menjadi mudah.

(Banyak proyek kecil tidak perlu melakukan percabangan jika dikelola dengan baik. Git ditujukan untuk kasus-kasus rumit; oleh karena itu sebagian besar dokumentasi Git mengasumsikan Anda perlu melakukan operasi kompleks seperti percabangan dan penggabungan.)


8
Menggunakan gitpercabangan dan penggabungan bukanlah operasi yang rumit. Saya bahkan menggunakan cabang dalam proyek one-man, bahkan ketika tidak ada persyaratan untuk beberapa versi. Terus bekerja, Anda tidak dapat melanjutkan saat ini di cabang, bercabang ketika Anda mengetahui bahwa mencoba solusi lain mungkin jauh lebih baik ... Namun, saya setuju itu gitagak sulit untuk dipelajari.
maaartinus

Kapan pun Anda perlu melakukan perbaikan bug di versi lama, Anda perlu bercabang dan menggabungkan.

1
Mengapa orang tidak menganggap gagasan bahwa lincah lebih mudah daripada svn atau git?
Warren P

Saya pikir sebagian darinya adalah karena SVN hingga saat ini belum mendukung percabangan dan penggabungan tanpa biaya yang sangat tinggi, itu memungkinkan programmer untuk lebih banyak membela manajer ketika mereka ingin terus mengubah apa yang sedang dikerjakan seseorang. Suatu alat harus bekerja di dalam kebijakan suatu perusahaan dan juga membantu membentuk kebijakan suatu perusahaan.
Ian

14

Yah, kakek saya bisa menggunakan SVN di komputer Windows XP-nya, tetapi dia akan kesulitan menggunakan Git. Mungkin ini lebih merupakan pencapaian TortoiseSVN daripada TortoiseGit , tapi saya pikir itu agak terkait dengan fakta, bahwa Git secara inheren lebih kuat dan dengan demikian lebih kompleks, dan tidak ada gunanya untuk membodohkannya ke level yang sama.

Sekarang tidak terlalu penting bagi kakek saya, karena dia belum melakukan pemrograman apa pun sampai akhir-akhir ini. Namun, saya pernah menjadi anggota tim, di mana seniman grafis kami juga menggunakan kontrol sumber kami.

Dan mereka adalah orang-orang yang hanya berharap alat mereka berfungsi (demikian juga saya, tetapi saya memiliki kesempatan yang realistis untuk membuat mereka bekerja jika terjadi kegagalan) dan bersifat intuitif. Terlepas dari kenyataan, bahwa itu akan menjadi upaya yang cukup untuk membuat mereka bergaul dengan DVCS , ada sedikit yang bisa diperoleh. Dan dengan hanya dua pemrogram dalam tim, masuk akal bagi kami untuk tetap menggunakan SVN.


git adalah pendekatan yang lebih "filosofis" untuk kontrol versi. Anda mulai berpikir tentang semantik komit, cabang, dll. Jadi orang yang ingin menggunakan VCS sebagai "cadangan" dan alat distribusi memiliki waktu yang lebih sulit, tetapi git tidak jauh lebih sulit
wirrbel

11

Di tempat kerja saya tidak bisa mengalihkan pengembang dari SVN ke DVCS apa pun karena dua alasan:

  • Pemeriksaan sebagian (seperti hanya tiga folder dari kedalaman berbeda di pohon proyek)
  • Penguncian file (laporan format biner)

8
  • Rasa aman ketika melakukan 'svn commit'. Karena komit masuk ke server, tidak ada kemungkinan sekrup yang dapat saya lakukan yang akan menghapus perubahan saya setelah dilakukan. Di git, komit adalah lokal, jadi sampai saya dorong, nyasar 'rm -rf' dan semuanya sudah berakhir.
  • Komit diautentikasi. Secara default di git saya dapat mengatakan bahwa saya berkomitmen sebagai siapa pun.
  • Lebih sedikit perintah untuk dipelajari untuk penggunaan sehari-hari. 'svn checkout', 'svn up', dan 'svn commit' akan membuat Anda cukup jauh.
  • Checkout bersama bekerja jauh lebih baik. Ketika Anda pergi untuk melakukan, itu meminta Anda untuk nama pengguna / kata sandi Anda, Anda tidak harus ingat untuk melewati argumen baris perintah tertentu. Kadang-kadang di tempat kerja kami memiliki mesin bersama dengan checkout svn bersama dari beberapa proyek. Seseorang mungkin berkata "Bob, bisakah kamu melihat ini di mesin ini" dan dia bisa, dan dia bisa melakukan perubahan sebagai penggunanya tanpa ada gangguan.
  • Tata letak repositori. Anda dapat memiliki proyek payung dan sub proyek dan memilih apa yang harus diperiksa kapan.
  • Angka revisi adalah bilangan bulat yang bertambah.
  • Dirancang untuk alur kerja repositori pusat.

+1 untuk masalah otentikasi. Git commit perlu ditandatangani, dan penandatanganan perlu diperiksa mana yang sulit.
Christian

6

Orang lain telah memposting beberapa jawaban yang cukup bagus, tetapi bagaimana dengan Izin? Menggunakan Subversion over SSH, Anda dapat membuat akun terpisah di server Anda untuk SVN. Pengembang yang berbeda dapat diberikan akses yang berbeda ke berbagai bagian repositori. Bisakah GIT melakukan itu? Saya kira ada gitolit, tapi sepertinya tidak sefleksibel atau sekuat saya, saya juga tidak kenal siapa pun yang benar-benar menggunakannya.


2
Yang lain mengatakan ini dengan menyebutkan "kontrol manajerial top-down". Ini adalah elemen kunci untuk lingkungan saya - kami memiliki area tertentu dari repositori kami yang perlu dikunci untuk dibaca-saja atau bahkan tidak-baca untuk beberapa grup pengguna. Kita juga perlu memiliki satu lokasi yang bisa kita tunjuk dan berkata "ini adalah salinan master yang resmi, jika salinan Anda tidak cocok dengan apa yang ada di sini, itu tidak resmi."
alroc

1
repositori yang diberkati dari pimpinan proyek dan letnan memberi kendali atas siapa yang dapat melakukan. Git repo diterbitkan pada server yang diaktifkan http-auth (menggunakan modul apache yang sama seperti yang dilakukan svn) melakukan otentikasi dan mengatakan siapa yang dapat mengkloning / checkout apa. Tentu, ini tidak granular seperti svn per izin direktori bisa, tetapi bagi saya itu lebih mirip manajemen mikro daripada kebutuhan sebenarnya.
Hubert Kario

@ HubertKario - ini menimbulkan pertanyaan, "Haruskah programmer terbaik Anda menghabiskan waktu memeriksa kode orang lain?" Sebenarnya, saya sangat tertarik dengan jawaban untuk pertanyaan ini, sehingga saya mempostingnya di sini: programmers.stackexchange.com/questions/181817/…
GlenPeterson

5

Kecepatan. Kadang-kadang membutuhkan waktu 10 atau 15 menit untuk mengkloning repositori big git, sementara repositori subversi berukuran serupa membutuhkan waktu beberapa menit untuk check out.


6
Tetapi checkout / kloning adalah operasi yang jarang terjadi. Dalam sebagian besar skenario, git lebih cepat daripada subversi.
rds

5
git clone --depth=1adalah teman Anda jika Anda tidak peduli dengan sejarah
Hubert Kario

4

Saya memposting ini sebagai tanggapan daripada komentar.

Saya akui bahwa DVCS sedang dalam tren saat ini, tetapi saya akan mencoba memberi tahu alasannya.

DVCS lebih baik karena sama seperti banyak orang mengatakan, "ini adalah cara kita seharusnya bekerja sejak awal". Memang benar, Anda dapat melakukan dengan DVCS apa yang Anda gunakan dengan SVN, sehingga dengan cara yang membuat SVN usang.

Namun, tidak setiap proyek perangkat lunak sebagus yang didapat:

  • Proyek jangka panjang memiliki banyak manfaat dari DVCS, karena menggunakan lebih sedikit overhead, memungkinkan manajemen yang jauh lebih baik (bercabang dll), dan sangat didukung oleh host seperti kode google dan github.

  • Proyek-proyek itu bukan satu-satunya, ada jenis proyek lain yang sedang dikembangkan di perusahaan-perusahaan tanpa bantuan dari dunia luar atau internet: semuanya dilakukan secara internal, dan seringkali dalam jangka pendek. Contoh yang bagus: gim video. Kode berkembang dengan cepat.

Untuk kasus yang terakhir, pengembang tidak benar-benar membutuhkan percabangan atau fitur canggih yang dapat ditawarkan DVCS, mereka hanya ingin berbagi kode sumber dan aset. Kode yang mereka buat sepertinya tidak akan digunakan kembali, karena ada tenggat waktu. Mereka mengandalkan SVN daripada DVCS karena beberapa alasan:

  • Pengembang memiliki mesin milik perusahaan, dan ini mungkin berubah dengan cepat. Mengkonfigurasi repo adalah kehilangan waktu.
  • Jika orang-orang itu tidak memiliki mesin sendiri, mereka cenderung bekerja pada kode sumber / bagian proyek yang sama. Ditambah satu untuk data terpusat.
  • kecepatan jaringan dan uang besar memungkinkan penggunaan server terpusat yang menangani segalanya SVN, itu praktik buruk tetapi cadangan dibuat dll.
  • SVN hanya lebih sederhana untuk digunakan, bahkan jika itu cara yang salah: menyinkronkan file pada rekan tanpa redundansi bukanlah masalah yang sederhana, dan "melakukannya dengan cara yang benar" tidak dapat membuatnya tepat waktu jika Anda selalu menginginkannya sempurna.

Pikirkan tentang mesin industri game dan bagaimana SVN adalah penghemat waktu; orang berkomunikasi lebih banyak pada proyek-proyek itu karena permainan adalah tentang pemrograman berulang dan kode adaptif: tidak ada yang sulit untuk dikodekan, tetapi itu harus dilakukan dengan cara yang benar, SECEPATNYA. Programmer dipekerjakan, mereka mengkode bagian mereka, kompilasi, mengujinya sedikit, melakukan, melakukan, penguji permainan akan berurusan dengan sisanya.

DVCS dibuat untuk internet dan untuk proyek yang sangat kompleks. SVN adalah untuk proyek tim kecil, jangka pendek, dan ketat. Anda tidak perlu belajar banyak dari SVN, ini hampir seperti FTP dengan diff bodoh.


Bisakah Anda menjelaskan contoh industri game?
johnny

3

Subversion dan Git keduanya mendorong pendekatan khusus (dan sangat berbeda) untuk pengembangan dan kolaborasi. Beberapa organisasi akan mendapatkan lebih banyak dari Git, dan yang lain akan mendapatkan lebih banyak dari Subversion, tergantung pada organisasi dan budaya mereka.

Git dan Mercurial sangat baik untuk tim programmer profesional yang sangat kompeten dan terdistribusi secara longgar. Kedua alat DVCS yang populer ini mendorong repositori kecil, dengan penggunaan kembali antara pengembang yang dilakukan melalui perpustakaan yang diterbitkan dengan (relatif) antarmuka yang stabil.

Subversion, di sisi lain, mendorong struktur manajemen yang lebih terpusat dan erat, dengan lebih banyak komunikasi antara pengembang dan tingkat yang lebih besar dari kontrol organisasi atas kegiatan pengembangan sehari-hari. Dalam tim yang lebih terorganisir ini, penggunaan kembali antar pengembang cenderung terjadi melalui perpustakaan yang tidak dipublikasikan dengan (relatif) antarmuka yang tidak stabil. TortoiseSVN juga mengizinkan Subversion untuk mendukung tim multidisiplin dengan anggota yang bukan pemrogram profesional (mis. Insinyur sistem, insinyur algoritme, atau spesialis bidang mata pelajaran lainnya).

Jika tim Anda didistribusikan, dengan anggota yang bekerja dari rumah atau dari berbagai situs internasional, atau jika mereka lebih suka bekerja sendiri dan dalam keheningan, dengan sedikit komunikasi tatap muka, maka DVCS seperti Git atau Mercurial akan bagus. kecocokan budaya.

Jika, di sisi lain, tim Anda terletak di satu situs, dengan pendekatan "tim" aktif untuk pengembangan, dan banyak komunikasi tatap muka, dengan "buzz" di udara, maka SVN mungkin merupakan kecocokan budaya yang lebih baik, terutama jika Anda memiliki banyak tim lintas disiplin.

Tentu saja, adalah mungkin untuk mengkonfigurasi Git dan Hg (kuat dan fleksibel seperti mereka) untuk melakukan hampir apa pun yang Anda inginkan, tetapi itu jelas lebih banyak pekerjaan, dan mereka jelas lebih sulit untuk digunakan, terutama bagi anggota tim yang secara alami tidak akan cenderung menggunakan segala bentuk kontrol versi apa pun.

Akhirnya, saya juga menemukan bahwa berbagi fungsionalitas menggunakan pengembangan perpustakaan "panas" di bawah Svn (dengan CI & pendekatan berbasis tes) memungkinkan kecepatan pengembangan terkoordinasi yang sulit dicapai dengan tim yang lebih terdistribusi dan longgar.



1

Ada dua tren utama dalam kontrol versi saat ini; Distribusi, dan Integrasi .

Git hebat dalam desentralisasi.

SVN memiliki banyak alat yang dibangun yang terintegrasi dengannya. Sudah umum untuk menyiapkan server SVN Anda sehingga ketika Anda memeriksa perbaikan, Anda menyebutkan nomor bug di komentar checkin, dan secara otomatis menetapkan itu tetapi ke keadaan "dalam pengujian", dan memperingatkan penguji yang ditugaskan bahwa mereka perlu Lihat itu. Kemudian Anda dapat menandai rilis dan mendapatkan daftar semua bug yang diperbaiki dalam rilis ini.

Alat yang melakukan ini dengan SVN sudah matang, dan digunakan setiap hari.


-1

Di Subversion, Anda dapat mengedit pesan log (juga disebut "komit pesan") setelah komit dilakukan dan didorong. Untuk sebagian besar penggunaan praktis, hal ini mustahil dilakukan dengan desain dalam sistem desentralisasi, termasuk git. Tentu saja, di git Anda dapat melakukan "git commit - amend", tetapi itu tidak membantu Anda setelah komit Anda didorong ke tempat lain. Di SVN, ketika Anda mengedit pesan log, Anda melakukannya di repositori pusat yang dibagikan semua orang, sehingga semua orang akan mendapatkan suntingan, dan tanpa pengubah revisi perubahan.

Mengedit pesan log setelah faktanya seringkali sangat berguna. Selain hanya memperbaiki kesalahan atau kelalaian dalam pesan log, ini memungkinkan Anda untuk melakukan hal-hal seperti memperbarui pesan log untuk merujuk ke komitmen di masa depan (seperti revisi yang memperbaiki bug atau menyelesaikan pekerjaan yang diperkenalkan dalam revisi saat ini) .

Ngomong-ngomong, tidak perlu ada bahaya kehilangan informasi. Kait pre-revprop-change dan post-revprop-change dapat menyimpan riwayat pesan lama jika Anda benar-benar khawatir, atau mengirim email dengan diff pesan log (ini lebih umum, sebenarnya), sehingga ada jejak audit.


1
ini juga mudah dilakukan di git; misalnya, git --amend; cara lain untuk melakukan ini adalah melalui git reset --soft HEAD ^, yang hanya berjalan kembali tetapi tidak mengubah indeks, dan sehingga Anda dapat mengedit / menulis ulang pesan komit.
doug

Hai, kawan. Ya, Anda dapat melakukannya untuk repositori lokal Anda, tetapi saya bicarakan begitu Anda mendorong perubahan di tempat lain - "git commit --amend" tidak banyak membantu Anda saat itu. Di SVN, Anda dapat mengedit pesan log di server pusat, tepatnya karena ada konsep server pusat. Itulah yang saya maksudkan dengan "mustahil dengan desain dalam sistem desentralisasi". Saya akan mengedit jawaban saya untuk memperjelas ini.
Karl Fogel

1
Saya suka bagaimana "Anda bisa bermain-main dengan sejarah" diduga fitur . Saya akan menganggapnya sebagai bug jika tidak disengaja.
cao
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.