SVN Git'ten daha iyi ne yapar? [kapalı]

Programcı araçlar üzerindeki tartışmaların çoğunluğunun kişisel tercihlere (kullanıcı tarafından) veya tasarım vurgusuna , yani tasarımı belirli kullanım durumlarına göre (araç üreticisi tarafından) optimize etmesine şüphe yok . Metin editörleri muhtemelen en belirgin örneğidir - iş ve kodlarına Windows üzerinde çalışan bir kodlayıcı Haskell evde Mac'te, çapraz platform ve derleyici entegrasyonu değerleri ve böylece seçer Emacs üzerinde TextMate vb

Yeni tanıtılan bir teknolojinin, mevcut seçeneklerden gerçekten ve gözle görülür şekilde üstün olması daha az yaygındır.

Aslında sürüm kontrol sistemleri (VCS), özellikle merkezi VCS ( CVS ve SVN ), dağıtılmış VCS'ye ( Git ve Mercurial ) mı?

SVN'yi yaklaşık beş yıl kullandım ve şu anda çalıştığım yerde SVN kullanılıyor. Üç yıldan biraz daha az bir süre önce, tüm kişisel projelerim için Git'e (ve GitHub) geçtim.

Git Subversion'un bir çok avantajını düşünebilirim (ve çoğu için merkezi VCS'ye dağıtılmış olan avantajların özetidir), ancak bir kontra örneğini düşünemiyorum - bazı görevler (her zamanki programcılarda ortaya çıkmaktadır) iş akışı) bu Subversion Git'ten daha iyi sonuç veriyor.

Bundan çıkardığım tek sonuç hiçbir veriye sahip olmadığımdır - Git'in daha iyi olması vs.

Benim tahminim, bu tür karşı örneklerin var olduğu, dolayısıyla bu sorudur.

Yıkılma merkezi bir depo

Pek çok insan hızın ve çoklu kopyaların bariz yararları için havuzlar dağıtmak isteyecek olsa da, merkezi bir havuzun daha fazla istendiği durumlar vardır. Örneğin, kimsenin erişmesini istemediğiniz kritik bir kod parçanız varsa, muhtemelen Git'in altına koymak istemezsiniz. Birçok şirket kodlarını merkezi tutmak istemektedir ve (sanırım) tüm (ciddi) hükümet projeleri merkezi depoları altındadır.

Yıkılma geleneksel bilgeliktir

Bu, birçok insanın (özellikle yöneticiler ve patronlar) versiyonları numaralandırmanın ve gelişimini beyninde kodlanmış zaman boyunca “tek bir hat” olarak görmenin olağan yoluna sahip olduğunu söylemek içindir. Alınma ama Git'in özgürlüğünü yutması kolay değil. Git kitaplarının ilk bölümü, tüm geleneksel idealleri zihninizden boşaltmanızı ve yeniden başlamanızı söyler.

Subversion bir şekilde yapar, başka bir şey yapmaz

SVN, bir sürüm kontrol sistemidir. It has bir işini yapmak için bir yol ve herkes bunu aynı şekilde yapar. Dönemi. Bu, SVN'den diğer merkezi VCS'ye / dan diğerine geçişi kolaylaştırır. Git saf bir VCS bile DEĞİL - dosya sistemi, farklı durumlarda depoları nasıl kuracağınız konusunda birçok topolojiye sahip - ve herhangi bir standart yok. Bu, birini seçmeyi zorlaştırır.

Diğer avantajlar:

• SVN boş dizinleri destekliyor
• SVN daha iyi Windows desteğine sahip
• SVN bir alt ağacı kontrol edebilir / klonlayabilir
• SVN, svn lockbirleştirilmesi zor dosyalar için kullanışlı olan özel erişim kontrolünü destekler
• SVN, ikili dosyaları ve büyük dosyaları daha kolay destekler (ve eski sürümlerin her yere kopyalanması gerekmez).
• Bir taahhüt eklemek önemli ölçüde daha az adım içerir, çünkü herhangi bir çekme / gönderme yoktur ve yerel değişiklikleriniz her zaman dolaylı olarak yeniden oluşturulur svn update.

Git'teki Subversion'un bir yararı, Subversion'un yalnızca alt ağaçları kontrol etmesine izin vermesi olabilir . Git ile tüm depo bir birimdir, yalnızca tümünü ya da hiçbirini elde edebilirsiniz. Modüler kodla, Git alt modüllerine kıyasla bu oldukça iyi olabilir. (Git alt modülleri de belli ki yerini alırken)

Ve küçük bir avantaj: Subversion, boş dizinleri izleyebilir. Git dosya içeriğini izler, böylece herhangi bir dosya içermeyen bir dizin görünmez.

Üç tane düşünebilirim. İlk olarak, özellikle geliştiriciler için, grok, biraz daha kolaydır. Kavramsal olarak DCVS seçeneklerinden daha basittir . İkincisi vadedir, özellikle Windows'ta TortoiseSVN . Kaplumbağa Hg olsa hızlı yetişiyor. Üçüncüsü, canavarın doğası - sadece ağacın herhangi bir seviyesinden şeyleri kontrol edebileceğiniz bir dosya sisteminin görüntüsü - bazı senaryolarda oldukça kullanışlı olabilir - düzinelerce geniş çapta farklı konfigürasyon dosyalarını yayınlamak gibi onlarca depo içermeyen sunucular.

Bu, tüm gelişmeyi Mercurial'a aktarmadığımız anlamına gelmez.

• SVN depoları, bir yöneticinin ve yöneticinin bakış açısından daha yönetilebilirdir ( ACL + doğrulama yöntemleri + hotcopy + mirrors + dump)
• SVN *-kancaların uygulanması ve desteklenmesi daha kolaydır
• svn:external alt modüllerden daha fazla güce ve esnekliğe sahiptir
• Dosya sistemi tabanlı depo ağaçlarının kullanımı yalnızca mantıksal olarak ayrılan monolitik havuzlardan daha kolaydır
• SVN daha farklı müşteri araçlarına sahip
• SVN, Git'inkinden çok daha iyi, üçüncü tarafların kullanabileceği web ön yüzlerine sahip
• SVN beyninizi kırmaz

Bunu başkasının cevabı üzerine bir yorum olarak yazdım, ama sanırım kendi başına bir cevap olmayı hak ediyor.

Şirketimin SVN için dikkatlice seçtiği yapılandırma, içeriği düzenlemek için dosya düzeyinde kilitleme gerektiriyor ve hiçbir zaman birleştirme kullanmıyor. Sonuç olarak, birçok geliştirici kilitler için mücadele eder ve bu büyük bir darboğaz olabilir ve asla bir birleşme çatışması olasılığı yoktur.

SVN kesinlikle yukarıdan aşağıya yönetim kontrolünü Git'ten daha iyi yapıyor. Skunkworks'ümde Git'e (izin yerine affetmek istiyor) göçüm, yöneticilerimden hepimizin köle olduğumuz herhangi bir yazılım tarafından uygulanan merkezi ana kontrol sunucusunun olmadığı düşüncesiyle dehşete düştüm.

Sebeplerim:

• vade - hem sunucu hem de araçlar (örneğin TortoiseSVN)
• basitlik - daha az adım dahil, bir taahhüt bir taahhüttür. Git ve Mercurial gibi DVCS, taahhüt etmeyi ve ardından ittirmeyi içerir.
• İkili kullanım - SVN, ikili çalıştırılabilir dosyaları ve görüntüleri Git / Hg'den daha iyi kullanır. Özellikle .NET projelerinde kullanışlıdır, çünkü inşa ile ilgili araçları kaynak kontrolünde kontrol etmeyi seviyorum.
• numaralandırma - SVN, sadece rakamları kullanarak okunabilir bir taahhüt numaralandırma düzenine sahiptir - revizyon numaralarını izlemek daha kolaydır. Git ve Hg bunu oldukça farklı yapar.

İyi bilgi aradığınızı takdir ediyorum, ancak bu tür bir soru sormaya davet ediyor: "Git'in çok kazandığını düşünüyorum ve suxorz svn!" cevapları.

Git ve şahsen Git'i küçük ekibim için biraz fazla buldum. Coğrafi olarak dağılmış büyük bir dağınık ekip veya takım grubu için harika olacak gibi görünüyordu. Git'in yararlarını çok iyi anlıyorum ama bence kaynak kontrolü beni geceleri ayakta tutan bir şey değil.

Ben bir geyik avcısıyım ve arkadaşlarımla dışarı çıktıklarında dişlere silahlanıyorlar, cephane ve yüksek teknolojili teçhizatla dolular. Tek bir tüfek, yedi kurşun ve bir de bıçakla görünüyorum. Yedi turdan fazlasına ihtiyacım olursa, o zaman yanlış bir şey yapıyorum ve ben de herkes gibi yapıyorum.

Yapmaya çalıştığım nokta, orta ve küçük ölçekli projeler üzerinde çalışan küçük bir ekipseniz ve zaten SVN ile aşina iseniz, onu kullanın. CVS veya (titreme) SourceSafe'den kesinlikle daha iyidir ve bir havuz oluşturmak beş dakikadan fazla sürmüyor. Git bazen fazlaca olabilir.

Bunların hepsi görecelidir ve maple_shaft'ın dediği gibi biri sizin için çalışıyorsa değişmeyin!

Ancak gerçekten bir şey istiyorsanız , tasarımcılar, web programcıları ve benzerleri için belki daha iyi olduğunu söyleyebilirim - görüntüleri ve ikili dosyaları biraz daha iyi ele alır.

Kullanılabilirlik. Bu gerçekten Subversion'un esası değil, aksine TortoiseSVN 'dir. TortoiseGit var, ancak TortoiseSVN ile eşleşmek için hala çok uzun bir yolu var.

Git'in SVN'den daha iyisini yaptığını sorarsanız GitHub'a cevap veririm . Üçüncü taraf araçların bu kadar büyük bir fark yaratması ne kadar komik.

Ne zaman şube ve birleştirme gerekmez (ile, SVN TortoiseSVN Windows üzerinde) anlamak ve kullanımı çok kolaydır. Git, dallanma / birleşmeyi kolaylaştırmaya çalıştığı için basit durumlar için aşırı karmaşıktır.

(Çok sayıda küçük projenin iyi yönetilmesi durumunda dallanması gerekmez. Git karmaşık durumlara yöneliktir, bu nedenle çoğu Git belgesi dallanma ve birleştirme gibi karmaşık işlemler yapmanız gerektiğini varsayar.)

Büyükbabam Windows XP bilgisayarında SVN kullanabilirdi ama Git'i kullanmakta zorlandı. Belki de bu, TortoiseGit'e göre TortoiseSVN'nin bir başarısıdır , ancak Git'in doğası gereği daha güçlü ve dolayısıyla daha karmaşık olduğu ve bunun aynı düzeye indirilmesi anlamsız olacağı kanısındayım.

Artık büyükbabam için hiç önemi yok, çünkü geç saatlerden beri herhangi bir programlama yapmadı. Ancak, bir zamanlar grafik sanatçılarımızın kaynak kontrolümüzü de kullandığı bir takımdaydım.

Ve onlar sadece aletlerinin çalışmasını bekleyen insanlar (ben de öyleyim, ama başarısızlık durumunda çalışmalarını sağlamak için gerçekçi bir şansım var) ve sezgisel olmaları. DVCS ile anlaşmaları için oldukça çaba sarf etmesi gerçeğinden ayrı olarak, kazanılacak çok az şey vardı. Ve takımdaki sadece iki programcı ile, SVN'e bağlı kalmamız bizim için bir anlam ifade etti.

İşyerinde iki nedenden dolayı geliştiricileri SVN'den herhangi bir DVCS'ye geçiremedim :

• Kısmi ödeme (proje ağacındaki farklı derinliklerden yalnızca üç klasör gibi)
• Dosya kilitleme (ikili format raporları)

• Bir 'svn taahhüdü' yaparken güvenlik duygusu. Taahhütler sunucuya gittiği için, yaptıklarımı yaptıktan sonra değişikliklerimi silecek yapabileceğim bir hata oluşmaz. Git'te, yerel bir emirdir, ittiğim zamana kadar başıboş bir 'rm -rf' olur ve her şey biter.
• Taahhütler onaylandı. Git'te varsayılan olarak herkes olarak iş yaptığımı söyleyebilirim.
• Günlük kullanım için öğrenmek için daha az komut. 'svn ödeme', 'svn' ve 'svn taahhüdü' sizi oldukça uzağa götürecektir.
• Paylaşılan çıkışlar çok daha iyi çalışır. Taahhüt ettiğinizde, sizden kullanıcı adınızı / şifrenizi sorar, belirli komut satırı argümanlarını iletmeyi hatırlamanız gerekmez. Bazen işte bazı projelerin ortak svn ödemeli ortak bir makinemiz var. Birisi "Bob'a bu makinede bakabilir misin?" Diyebilir ve yapabilir ve değişiklik yapmadan kullanıcı olarak değişiklik yapabilir.
• Havuz düzeni. Bir şemsiye projeye ve alt projelere sahip olabilir ve ne zaman kontrol edeceğinizi seçebilirsiniz.
• Revizyon numaraları, tamsayıları artırıyor.
• Merkezi depo iş akışı için tasarlanmıştır.

Diğer insanlar da oldukça iyi cevaplar verdiler, peki ya İzinler? SSH üzerinden Subversion kullanarak, sunucunuzda SVN için ayrı bir hesap oluşturabilirsiniz. Farklı geliştiricilere, havuzun farklı bölümlerine farklı erişim izni verilebilir. GIT bunu yapabilir mi? Sanırım, gitolit var, ama bana göre esnek ya da sağlam görünmüyor, ne de gerçekten kullanan birini tanımıyorum.

Hız. Bazen büyük bir git deposunu klonlamak 10 veya 15 dakika sürerken, benzer büyüklükteki bir çöküş deposu da kontrol etmek için birkaç dakika sürebilir.

Bunu yorum yerine bir cevap olarak gönderiyorum.

DVCS'nin şu an oldukça trendde olduğunu itiraf ediyorum, fakat nedenini anlatmaya çalışacağım.

DVCS daha iyi çünkü tıpkı birçok insanın dediği gibi, "bu en başından beri çalışmamız gereken şeydi". Doğru, SVN ile eski haline getirdiğiniz şeyleri DVCS ile yapabilirsiniz, böylece SVN'yi eski kılar.

Ancak, her yazılım projesi göründüğü kadar iyi değildir:

• Uzun vadeli projenin DVCS'den yararlandığı çok şey var, çünkü daha az ek yük kullanıyor, daha iyi yönetim sağlıyor (dallanma vb.) Ve google code ve github gibi ev sahipleri tarafından büyük ölçüde destekleniyor.

• Bu projeler tek değildir, dış dünyadan veya internetten yardım almadan şirketlerde geliştirilen başka tür projeler de vardır: her şey dahili olarak ve genellikle kısa vadede yapılır. İyi bir örnek: bir video oyunu. Kod hızla gelişir.

İkinci durumda, geliştiricilerin DVCS'nin sunabileceği dallanma veya karmaşık özelliklere gerçekten ihtiyacı yok, sadece kaynak kodunu ve varlıklarını paylaşmak istiyorlar. Yaptıkları kodun tekrar kullanılması muhtemel değildir, çünkü bir son tarih vardır. Birkaç nedenden dolayı DVCS yerine SVN'ye güveniyorlar:

• Geliştiricilerin şirkete ait makineleri var ve bu hızla değişebilir. Bir repo yapılandırmak zaman kaybıdır.
• Bu adamlar kendi makinelerine sahip değilse, projenin aynı kaynak kodunda / kısmında çalışıyor olma ihtimalleri daha düşüktür. Artı, merkezi veri için bir tane.
• ağ hızları ve büyük para, SVN ile her şeyin üstesinden gelen merkezi bir sunucunun kullanımına izin verir, kötü bir uygulamadır ancak yedekleme yapılır.
• SVN, yanlış yol olsa bile, kullanımı daha basittir : yedeklilik olmadan eşler üzerindeki dosyaları senkronize etmek basit bir sorun değildir ve "her zaman mükemmel olmasını istiyorsanız" doğru şekilde yapın ".

Oyun endüstrisi makinesini ve SVN'nin nasıl zaman kazandıracağını düşünün; insanlar bu projeler üzerinde çok daha fazla iletişim kuruyorlar çünkü oyunlar tekrarlayan programlama ve uyarlanabilir kodlar hakkında: kodlaması zor bir şey yok, ama doğru şekilde yapılması gerekiyor, asap. Programcılar işe alınır, rollerini kodlarlar, derlerler, biraz test ederler, işlerler, tamamlarlar, oyun testçileri geri kalanıyla ilgilenir.

DVCS internet ve çok karmaşık bir proje için üretilmiştir. SVN küçük, kısa vadeli, sıkı ekip projeleri içindir. SVN'den çok şey öğrenmenize gerek yok, aptal bir farkla neredeyse bir FTP.

Subversion ve Git, kalkınma ve işbirliğine yönelik özel (ve çok farklı) yaklaşımları teşvik ediyor. Bazı kuruluşlar Git'ten daha fazla yararlanırken, diğerleri de kuruluşlarına ve kültürlerine bağlı olarak Subversion'dan daha fazla yararlanacaktır.

Git ve Mercurial, oldukça yetenekli profesyonel programcıların dağıtılmış ve gevşek organize ekipleri için mükemmeldir. Bu popüler DVCS araçlarının her ikisi de (nispeten) kararlı arayüzlere sahip yayınlanmış kütüphaneler aracılığıyla gerçekleştirilen geliştiriciler arasında yeniden kullanımıyla küçük depoları teşvik eder.

Diğer taraftan, yıkım, geliştiriciler arasında daha fazla iletişim ve günlük gelişim faaliyetleri üzerinde daha fazla bir derece kurumsal kontrol derecesi ile daha merkezi ve sıkı bir şekilde birleştirilmiş bir yönetim yapısını teşvik eder. Bu daha kompakt bir şekilde organize olmuş ekipler içerisinde, geliştiriciler arasındaki yeniden kullanım, (nispeten) dengesiz arayüzleri olan yayınlanmamış kütüphaneler aracılığıyla gerçekleşme eğilimindedir. TortoiseSVN aynı zamanda Subversion'un profesyonel programcı olmayan üyelerle çok disiplinli takımları desteklemesine de izin verir (örneğin, sistem mühendisleri, algoritmalar mühendisleri veya diğer konu uzmanları).

Ekibiniz ya evden ya da birçok farklı uluslararası siteden çalışan üyelerle ya da çok az yüz yüze iletişim ile yalnız ve sessizce çalışmayı tercih ediyorlarsa, Git veya Mercurial gibi bir DVCS iyi olacaktır. kültürel uyum.

Öte yandan, ekibiniz gelişmekte olan aktif bir "ekip" yaklaşımı ve havada yüz yüze iletişim kurabilen tek bir sitede bulunuyorsa, SVN olabilir. Daha iyi kültürel uyum, özellikle çok sayıda disiplinlerarası ekibiniz varsa.

Elbette, Git ve Hg'yi (oldukları gibi güçlü ve esnek) ne istersen hemen hemen yapacak şekilde yapılandırmak mümkündür, ancak kesinlikle daha fazla iş vardır ve özellikle ekip üyeleri için kullanımı kesinlikle daha zordur. doğal olarak, herhangi bir sürüm kontrolü kullanmaya meyilli değildir .

Son olarak, Svn altında "sıcak" kütüphane geliştirmeyi kullanan (CI ve test odaklı bir yaklaşımla) işlevselliği paylaşmanın, daha dağınık ve gevşek bir şekilde birleştirilmiş bir ekiple elde edilmesi zor bir koordineli gelişim hızına izin verdiğini de biliyorum.

Aşağıda hala SVN ile kalmamın iki nedeni var.

1. Öğrenme eğrisi. SVN Git'ten, hatta kurulumdan (sunucu veya istemci), kullanılabilirlik ve komutlardan daha kolaydır.
2. Subversion Edge , VisualSVN , uberSVN vb. Gibi daha iyi sunucu paketleri

Şu anda sürüm kontrolünde iki ana eğilim var; Dağıtım ve Entegrasyon .

Git ademi merkeziyetçilikte harika.

SVN, onunla bütünleşen birçok araç içeriyor. SVN sunucunuzu ayarlamak, genel olarak bir düzeltme yaptığınızda, check-in yorumundaki hata numarasından bahsettiğiniz ve otomatik olarak bunu ancak "test etme" durumuna ayarlayan ve atanan test cihazına gerekli olduklarını bildiren bir sistemdir. ona bak. Ardından bir sürümü etiketleyebilir ve bu sürümde düzeltilen tüm hataların bir listesini alabilirsiniz.

SVN ile bunu yapan araçlar olgun ve her gün kullanılıyor.

Subversion'da, işlem tamamlandıktan ve ittikten sonra günlük iletilerini ("taahhüt mesajları" olarak da bilinir) düzenleyebilirsiniz. Pratik kullanımların çoğu için, git dahil merkezi olmayan sistemlerde tasarım yapmak imkansızdır. Elbette, git'te "git commit --amend" i yapabilirsiniz, ancak bu, taahhüdünüz başka bir yere itildikten sonra size yardımcı olmaz. SVN’de, günlük mesajını düzenlerken, bunu herkesin paylaştığı merkezi depoda yapıyorsunuz, böylece herkes düzenlemeyi alacak ve revizyonun tanımlayıcısı değişmeden.

Olaydan sonra günlük mesajlarını düzenlemek genellikle çok yararlıdır. Bir günlük mesajındaki bir hatayı veya bir ihmali düzeltmenin yanı sıra, gelecekteki bir taahhüte atıfta bulunmak için bir günlük mesajını güncelleme gibi şeyler yapmanıza olanak tanır (örneğin, bir hatayı düzelten veya mevcut revizyonda sunulan çalışmayı tamamlayan revizyon gibi) .

Bu arada, bilgi kaybı tehlikesi yoktur. Revprop-değişim ve revprop-değişim sonrası kancalar, gerçekten endişelendiyseniz eski mesajların geçmişini kaydedebilir veya günlük mesajı farkıyla birlikte e-postalar gönderebilir (bu daha yaygındır). denetim izi.