Git / mercurial / bazzr sistemlerinin neden merkezileştirilmiş sistemlerden (yıkım, performans) daha iyi olduğunu araştırdım ve herhangi bir ticari neden bulamadım .

Bir DVCS'yi teknik olmayan bir kişiye satmaya çalışıyor olsaydınız, DVCS'in karı için ne gibi argümanlar sunacaktınız .

Kısaca yöneticime gitmek için çalışacağım, yıkılma havuzlarını dönüştürmek biraz zaman alacaktır ve smartgit lisansı satın almak için biraz zaman harcayacağım.

Düzenleme Bu soruyu merkezileşmiş ve merkezileşmemiş hale getirme üzerine genel bir tartışma haline getirmeye çalıştım, ama kaçınılmaz olarak git ya da yıkılmaya dönüştü. Elbette yıkılmadan daha iyi merkezi sistemler var.

Hmm, menajer olduğum için buna iki an önce "dizliksiz" tepki verdim:

• Halihazırda iyi nedenleriniz yoksa neden trendy olmaktan başka gitmiyorsunuz?
• Benzer şekilde, Subversion bir yedeklemeye ihtiyacınız olacak şekilde nasıl başarısız oluyor?

Aslında, olumsuz olmuyorum - muhtemelen yapılması gereken bir durum olduğunu düşünüyorum (duruma bağlı olarak) ancak durum basitçe bu git yıkımdan "daha iyi" ise, o zaman gerçekten bir hakkınız yok.

Ayrıca, dezavantajları sıralayabilmeniz gerekir - göç ve yeniden takımlama ek yükünü zaten belirlediniz - başka ne sorun var? örn. Güzel, merkezi, yedeklenmiş havuzunuza ne olur? Sürekli entegrasyon derleme sunucunuzla nasıl bütünleşirsiniz (eğer sizde yoksa ilk önce git ve sırala). Ah güvenlik ve izleme - SVN uygun giriş ve izinlerle çalışır.

Aklıma göre, faydalar esneklik, daha iyi birleşme, yapıyı bozmadan yerel taahhütler yapma yeteneği ve daha fazlası. Dezavantajları kontrol eksikliği ve aynı esneklik.

Yapmanız gereken tek şey, "daha iyi" bir yıkılma istemcisi olarak makinenizde yerel olarak git çalıştırma olabilir (bunu mercurial kullanarak yapıyorum).

Hmm, belki de tüm bu cevap gerçekten bir yorumdur? Sen davanızı yapmak gerekir burada size olurluk belirlenmesine yardımcı olmadığını görmek için (ortamınızda) tahrip üzerinde Git için (söz konusu).

FWIW, havuzun / referans kaynağı olarak havuzun belirli bir örneğini kolaylıkla belirleyebileceğini ve bunun da birinin inşa sunucusuna bağlanma şeklinin daha kolay olduğunu biliyorum. mimaride doğal olan bir şey.

Çabuk ve ağrısız dallanma ve birleştirme işleminin geliştiricilerin kodlarıyla daha verimli olmalarına izin vereceğini söyleyebilirim, çünkü her yeni özellik dallanmış ve daha sonra birleştirilmiştir. Geliştirme sürecinin çok daha sorunsuz geçmesini sağlamak. Ayrıca, dağıtılmış doğa, her geliştiricinin kodun tam bir kopyasına sahip olmasını sağlayacaktır, bu nedenle merkezi bir sunucuda tüm kodunuzu devralma endişesi yoktur. Muhtemelen daha fazla sebep var, ancak ikisi, Git'i kullanmam için en önemli nedenler.

Geliştiricinin tek başına çalışması durumunda bile sürüm kontrolü için verimliliği artıran (ve dolayısıyla kar) artan bir durum sağlayabileceğinizi varsayıyorum.

İyi bir DVCS, ekibin bir parçası olarak çalışırken bile aynı verimlilik avantajlarını tanır - her geliştirici, sürüm kontrolü ile çalışmanın tüm avantajlarından yararlanabilir - sık sık taviz verebilir, geri alma yapabilir, işlerle uğraşabilir vb. - çatışmalardan endişe etmeden diğer geliştiricilerin yaptıkları değişiklikleri yapmak için hazır olana kadar.

• Şube başına hata
• Farkında daha az gecikme var.
• İçin güçlü olmak çok sen akran gözden geçirirken bir şube tarih boyunca hızla gezinmek keyfi.
• Merkezileştirilmiş sunucuya erişiminiz olmadığında hala tüm geçmişinize erişebilirsiniz: ofiste değilsiniz, elektrik kesildi ama dizüstü bilgisayarınızın bataryası hala çalışıyor ...

Bu şeyler hem solo hem de takım olarak daha verimli çalışmanıza izin veriyor. Daha verimli çalışma = daha hızlı gelişme süresi = pazara daha hızlı süre = kar.

Kendi bloguma bağlandığım için beni bağışlayın, ancak bu konuda yazılar yazdım:

• İpucu Neden Her Zaman Derlenmeli?
• DVCS neden daha iyi bir merkezi kontrol sağlar?
• Dallanma neden DVCS ile daha iyidir
• Neden dağıtılmış dallanma modelleri CVCS'nizde iyi çalışmayabilir ?

Bunları alakalı bulamazsanız, oy vermekten çekinmeyin.

Kısaca, DVCS, büyük geliştiriciler gruplarının birbirlerinin ayak parmaklarına basmasını engelleyebilecek dallanma modellerini kolaylaştırır; bu da hem üretkenliği hem de günlük yapım kalitenizi artırır. Sürüm kontrolünün dağınık işbirliği kısmı, yerel depolarda yapılabilir, bu sayede merkezi depo temizleyici ve daha yüksek kalitede kalır. Ayrıca, ne zaman şube açılacağına dair kararlar verimlilik üzerinde büyük bir etkiye sahip olabilir, örneğin, 1.0 hala başkaları tarafından temizlendiğinde bir departman 2.0'da çalışmaya başlamaya hazırsa. DVCS, bu kararların komite yerine yerel düzeyde alınmasını sağlar.

DVCS'ye yönelik argümanlarım:

• Dallanma bozulmaz, bu da özelliklerin geliştirilmesinde ve mevcut ürünlerin yamalarının tutulmasında daha az sürtünmeye yol açar. Sürtünme zamanla paraya mal olur.

• Modern bir sisteme geçmek, daha iyi ürün kültürüne yol açacak olan ve daha fazla ürün satabilmek için en gelişmiş geliştiricileri cezbeder.

• Ağ dışı taahhütler daha hızlıdır ve geliştiricilerin sık sık işlem yapmasına izin vererek ince taneli hata tespiti ve analizine yol açar.

Temel olarak, sürtünmeyi azaltmakla ilgili. Bunun için bir terim var: Muda . Ne kadar fazla sürtünme olursa, acı o kadar çok şey yapar. Ne kadar fazla acı çekerse o kadar az şey yapılır, kar o kadar az olur.

Gösterişsiz olduğum için özür dilerim, ancak iş vakasını belirsiz bir şekilde ifade etmeme izin ver:

SVN, geliştiricilerin hayatını perişan ediyor . Bu da bir yazılım işini perişan ediyor.

... DVCS kullanmaya başlayana kadar pek kimsenin farkına varamayacağı şekilde. Bu, olası bir iş olayı olabilir . Niye ya? Eh, iyi geliştiriciler bulma ve elde tutmanın maliyeti ile karşılaştırıldığında, bir DVCS'ye geçmenin maliyeti neredeyse yok denecek kadar azdır .

Aşağıdakileri göz önünde bulundur:

• SVN'deki en önemsiz işlemlerin tümü (ve çoğu diğer CVCS'ler) ağ erişimi gerektirir. Çoğu DVCS'de, ağ erişimi yalnızca bir işlemi pushveya pullişlemi yaptığınızda gerçekleşir. Bu, önemsiz olmayan komutların yavaş olduğu anlamına gelir . Bir emir sonsuza dek sürdüğünde ne yaparsın? Ben şahsen bekliyorum iken programmers.se veya hacker haber göz atın. Basitçe ifade etmek gerekirse, DVCS'ler programcıların sevdiklerini yapmaya odaklanmalarına izin verir: şirketin yazılımını yazma .
• SVN, aynı şekilde dallanma desteğine de sahiptir; hapishaneler duşta sabununuzu bırakma desteğine sahiptir: bunu yapabilirsiniz; Bu nedenle, SVN geliştiricilerinizi değişiklik yapmak için sürekli olarak birbirleriyle savaşmaya zorlar .
• SVN kapalı olduğunda, kapalıdır. Geliştiricilerin, eğer yapabiliyorlarsa işlerini yapmaları çok zorlaşır. Bu nedenle, SVN geliştiricilerinizi altyapınıza% 100 hatasız olarak güvenmeye zorlar .
• Bugünlerde git hızlı bir şekilde zihniyet kazanıyor, SVN ise hızla kaybediyor. DVCS'leri SVN üzerinden kullanmanın bir faydası yoksa, programlama topluluğu neden olabildiğince hızlı değişiyor?

Tüm bu miktar ne kadar? DVCS'ye verilen, daha sonra SVN'yi tercih edecek dürüst bir deneme verilen bir geliştiriciyle tanışmadım. Bir tane daha can sıkıcı, cesur bir ifade yapabilirsem, SVN geliştiricilerin kendilerini kullanmaya zorladığı "gerekli bir kötülük" tür. Git, geliştiricileri daha üretken ve daha mutlu yapan bir araçtır .

(Kalın harfli ifadelerin odaklanmanız gereken belirli ifadeler olduğunu belirtmeliyim. Geri kalanlar yalnızca içerik sağlar.)

Aklıma gelen tek şey git'in ağ bağlantısı olmadan çalışması. Her şey, bir süredir daldırma veya performans kullanan teknik kullanıcılara satmak için bile zor.

Sorun olduğunda fark gösterisi

On yıl öncesindeki eski depoya yerleştikten 6 ay önce git'e geçtik.

Şimdiye kadar biraz deney yaptıktan sonra, aşağıdakileri buldum:

• dallanma ve birleşme neredeyse ağrısızdır. Bu, birbirlerinin ayak parmaklarına basmadan ayrı özellikler ve hata düzeltme üzerinde çalışmayı çok daha kolaylaştırır. Ayrıca verilen bir düzeltmeyi başka bir yere de uygulamanızı kolaylaştırır.

• tasarım açısından daha sağlam - mevcut bir merkezi sunucuya% 100 güvenmiyorsunuz ve bu mümkün değilse herhangi bir klonu geçici olarak etkin bir yedek olarak kullanabilirsiniz. Bu önemli bir başarısızlık noktasını ortadan kaldırır - SVN sunucusu herhangi bir nedenden ötürü kapanırsa, kimse SVN işini yapamaz. Merkezi git deposu herhangi bir nedenden ötürü düşerse, komisyonların çoğaltıldığından emin olmak için hala çalışabilir ve yerel olarak itebilir / çekebilirsiniz. Tam da bu amaçla birden fazla site dışı depoya sahip olabilirsiniz.

• depo etkileşimi basitleştirilmiştir. CVS için temel olarak, bir parça bilgiye ihtiyaç duyduğunuzda her zaman erişmeniz gerekiyordu. Git için tüm depo yerel olarak mevcuttur ve birçok şeyin daha hızlı gitmesini sağlar.

Yani, fayda günlük rutinde olduğu kadar değil, doğru çalışmayan bir şeyin olduğu anda çok açık!

Dolayısıyla, iş durumunuz için, felaket başladığında ne yapacağınıza bakmanızı öneriyorum ...

Dallanma ve birleşme kolaylığı en somut nedendir, ancak birini ikna etmek için onlara bunları nasıl iyileştirdiğine dair somut bir örnek vermeniz gerekir.

Bir uygulama için performans iyileştirmeleri üzerinde çalışan birkaç programcınız olduğunu ve deneysel aşamada olduklarını ve yazdıkları kodun ana / ana dalın bir parçası olup olmayacağını bilmediğini varsayalım. Ancak, kodları birbirleriyle sık sık paylaşmaları ve çıkmaz olabilecek fikirleri denemeleri gerekir. Subversion'da bu kadar sık ​​dallanma ve birleşmeyi nasıl yönetiyorsunuz? Kısa cevap, yapmamanız. Bir dvcs ile bu gerçekten kolaydır ve programcılar şubelerdeki yeni fikirleri hızlı bir şekilde deneyebilir ve bu fikrin uyup uymayacağına karar vermeden önce başkalarıyla paylaşabilir.

SubVersion'un kazılması için iş vakası, dallanma desteğinin ürün stabilizasyonu ve bakımı için bir engeldir. Bir ürünü piyasaya sürmeniz ve daha sonra geliştirmeye devam etmeniz gerekiyorsa, bir şubeye ihtiyacınız vardır. Yıkımla birlikte, geliştiriciler dallanmayı doğru kullanmayacaklar ve böylece gelişmeye devam etmeyecek ve hata düzeltmelerinin hem gövdede hem de dalda olacağından emin olacaksınız.