Git kullanıcıları neden Subversion'un tüm kaynak kodunun yerel olarak bulunmadığını söylüyor?


23

Sadece SO'da okuduklarımdan devam ediyorum, o yüzden beni affet, ama okuduğum her şey Git’in Subversion’a göre en büyük avantajlarından birinin Git’in tüm kaynak kodunu yerel olarak geliştiriciye vermesidir. sunucu.

Sınırlı SVN ve TortoiseSVN kullanmayla birlikte, tüm kaynak kodunu aldım ya da en azından yaptığımı düşündüm. Mesela bir web sitem var. SVN'ye yüklüyorum. Hala web sitemi yerel olarak çalıştırıyorum, değil mi? Birisi bir değişiklik gönderirse ve bağlı değilsem, sunucuya yeniden bağlanana kadar Git yapıp yapmadığımın önemi olmaz.

Ben anlamıyorum. Bu nokta hariç, birinin diğerine karşılık gelmesini istemiyorum.


2
Yerel olarak tüm kaynak kodunuza sahip değilsiniz, yerel olarak tüm depo geçmişine sahipsiniz. Bu, sunucu senkronizasyonu dışındaki tüm depo etkileşimlerini çok daha hızlı hale getirir.
stonemetal

Yanıtlar:


69

Sorguladığınız öncül gerçekten yanlıştır:

Git'in Subversion'a göre en büyük avantajlarından biri Git’in tüm kaynak kodunu geliştiriciye yerel olarak vermesidir.

Hem Subversion hem de Git ile yerel olarak kaynak kodunuz var. Git ile yerel makinenizde hem kaynak kodunuz hem de bir depoya sahip olursunuz.

Böyle bir şey gider.

Subversion:

Kodunuz <-> Havuz

Git:

Kodunuz <-> Yerel deponuz <-> Uzak bir depo (... <-> başka bir uzak depo vb.)

Bu yapıdan aldığınız avantajlardan biri, kaynak kontrolünü kullanabilmeniz ve diğer ekip üyelerinin (uzak depoyu paylaştığınız) çalışmalarını rahatsız etmeden yerel değişikliklerinizi yerel deponuzda yapabilmenizdir.

Subversion ile, başkaları için yapıyı bozma riskiyle karşı karşıya kalmanız ya da büyük bir taahhüt (veya daha büyük olasılıkla geri dönüş) ile sonuçlanan herhangi bir kaynak kontrolü olmadan uzun süredir yerel kalkınma ile karşılaşmanız gerekir.

Öte yandan Git ile bu değişiklikleri yerel deponuza yapmaktan, günlükleri ve farkları veya değişikliklerinizi görüntülemektan çekinmeyin ve yalnızca ekiple paylaşılmaya hazır olduğunu hissettiğinizde değişiklikleri yerelden itin uzak olana depo.


10
Bu çok güzel bir cevap ve gerçekten de “başkaları için yapıyı riske atma riski ya da herhangi bir kaynak kontrolü olmadan uzun süredir yerel kalkınmaya maruz kalma riskiyle…”
Charles Sprayberry

1
@ cspray: Teşekkürler! Eminim başka faydalar da vardır, ama Svn ile yaşadığım en büyük acı bu.
Goran Joviç,

git FTW (gitmek için 8 daha fazla ...)
Trevor Boyd Smith

2
@DanNeely: Aslında öyle - OP bir yerlerde okuduğu bir hak talebini sordu ve cevabı sadece doğru değil (cevabımın ilk bölümüne bakınız). İkinci bölüm, iddiada bulunanın muhtemelen neyi söylemek istediğini ve nedenini açıklamaktan ibarettir.
Goran Joviç

1
@Giorgio: Deneyin ve bileceksiniz :) Cidden, bunu sorunsuz bir şekilde yapabileceğimi sanmıyorum (tamamen el ile bir birleştirme yapmak dışında, hangi tür aracın amacını yitirir)
Goran Jovic

17

Git veya Mercurial, tüm depolarınızı tüm revizyonları ve adlandırılmış şubeleriyle yerel olarak saklar. Subversion yalnızca bir tane depolar - genellikle Head Revizyonu. Böylece, Git ve Mercurial ile ağınız SVN'den ayrılsa bile, güncellemiş olduğunuz en son revizyonla sınırlandırılmış olsanız bile , tüm depoya (yani şu anki kaynak kodunuz ve geçmişi) erişebilirsiniz .


1
@Murph Teşekkürler. Esasen demek istediğim buydu. Aydınlatmaya çalıştım.
Amenti

Bu sadece sunucuya bir ağ bağlantınız olup olmadığı değil; Yerel IO, geçmişi incelemeyi veya bir dosyayı çok daha hızlı suçlamayı sağlayan ağ IO'sundan çok daha hızlı ve daha düşük gecikme süresidir (TrotiseSVN suçlama uyarısı "Lütfen bekleyin - bu birkaç dakika sürebilir. Cidden!"). Tradeoff, yerel tüm tarihe sahip olmanın, daha büyük havuzlarda daha fazla disk alanı gerektirebilmesidir; bu, dizüstü bilgisayarlarda sorun yaratabilir, bankadan daha küçük olmayan bir SSD'yi desteklemek için yalnızca fazladan bir sürücü ekleyemezsiniz.
Dan Neely

@ DanNeely'nin yorumu muhtemelen 2012'de makul değildi, ancak 4 yıl sonra bir SSD'nin herhangi bir büyük kısmını işgal edebilecek bir git projesi bulmak neredeyse imkansız
Igor Stoppa

7

Kısa cevap şudur: git ile tüm kaynak kodunuz vardır, subversiyon ile kaynak kodunuzun en son sürümüne sahip olursunuz.

Git, deponuzun tarihçesinin bir kopyasını yerel olarak saklar. Subversion ile tüm tarih bir sunucuda.


2

Bence varabileceğiniz şey, SVN ile tüm eylemlerinizin, GIT'in yapmadığı şekilde sunucu ile iletişim gerektirmesidir. SVN ile dallanma yapmak istiyorsanız, sunucuda dallanma yapar ve daldan aşağı çekersiniz. GIT ile "sunucu" nu hiç bilmeden yerel bir şube oluşturabilirsiniz.

Hem SVN hem de GIT ile birlikte kaynak koduna sahip olduğunuzu söylemekte haklısınız, ancak GIT'de, kaynak kodunu da içeren merkezi bir sunucu olması gerekmez. GIT ile, kaynak kodlu SADECE kişi olabilirsiniz, ancak yine de tipik bir VCS ile yapacağınız tüm işlevleri yapabileceksiniz.

GIT aleyhindeki argümanları duydum ve bunun merkezi bir repo yapmak zorunda olmadığınızdan, kaynak kodunuzu kendi isteğinize ve sunucunuza itinceye kadar kullanmanız gerektiğini söyleyerek sorunuza yardımcı olabileceğini düşünüyorum. sende bir tane var. SVN ile sürüm kontrolüne sahip olmanın tek yolu, sunucuya çalışmaktır, ancak GIT ile yerel makinenizde her şeyi potansiyel olarak tutabilirsiniz ve herhangi bir sorun çıkarsa bile, her şeyi kolayca yapabilseniz bile "her şeyi kaybedebilirsiniz" taahhütte bulunmazsanız ve HDD’niz de düştüğünde, tüm değişikliklerinizi SVN’de kaybedersiniz.


1

merkezi bir repo yapmak zorunda olmadığınızdan, kaynak kodunuzu sahiplenene ve sunucunuza itinceye kadar sahip olduğunuzu söyleyerek. SVN ile sürüm kontrolüne sahip olmanın tek yolu, sunucuya çalışmaktır, ancak GIT ile yerel makinenizde her şeyi potansiyel olarak tutabilirsiniz ve herhangi bir sorun çıkarsa bile, her şeyi kolayca yapabilseniz bile "her şeyi kaybedebilirsiniz" taahhütte bulunmazsanız ve HDD’niz de düştüğünde, tüm değişikliklerinizi SVN’de kaybedersiniz.

Her gün zorlarsanız, risk küçük olmalıdır. Ancak, SVN sunucusuna günlük olarak işlem yapmak zorunda kalırsanız, günün sonunda, her değişikliği küçük adımlara ayırmayan tek bir büyük değişiklik setinde yapabilirsiniz. Git ile birden fazla küçük taahhütte bulunmanız teşvik edilir. Bastırırken, birleştirme gerekirse, birleştirme ve bastırma. Şu anda birleştirme yapamıyorsanız, sunucudaki yeni bir şubeye veya başka bir depoya basabilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.