Dağıtılmış sürüm kontrol sisteminin (DVCS) faydalarını anlamaya çalışıyorum.
Mercurial ve diğerleri DVCS, değişiklik setleri ve yerel taahhütlerle kod üzerinde yeni bir çalışma yöntemi sağlar. Cehennem ve diğer işbirliği konularının birleşmesini önler
Denediğimiz sürece sürekli entegrasyon ve özel bir dalda tek başına çalışmak bir seçenek değil, bundan etkilenmiyoruz. Bagajdan birleştirilen hataları düzelttiğimiz her ana sürüm için bir şube kullanıyoruz.
Mercurial teğmen almanıza izin verir
Bunun Linux gibi çok büyük projeler için yararlı olabileceğini anlıyorum, ancak değeri küçük ve işbirlikçi ekiplerde (5 ila 7 kişi) görmüyorum.
Mercurial daha hızlıdır, daha az disk alanı kaplar ve tam yerel kopyalama daha hızlı günlük ve diffs işlemleri sağlar.
Üzerinde çalıştığım çok büyük projelerde bile SVN ile hız veya alan problemleri fark etmediğim için bu konuda da endişelenmiyorum.
Eski SVN meraklılarının kişisel deneyimlerini ve/veya görüşlerini arıyorum. Özellikle değişiklik setleri kavramı ve ölçtüğünüz genel performans artışı ile ilgili.
GÜNCELLEME (12 Ocak) : Şimdi denemeye değer olduğuna ikna oldum.
GÜNCELLEME (12 Haziran) : Mercurial'ı öptüm ve beğendim. Onun kiraz yerel tadı taahhüt eder. Mercurial'ı sadece denemek için öptüm. Umarım SVN Sunucum aldırmaz. Çok yanlış geldi. Çok doğru geldi. Bu gece aşık olduğum anlamına gelmiyor .
Not: Mevcut sorunun cevabı için bkz. "EDIT"
Her şeyden önce Joel Spolsky'nin Subversion Re-education bölümünü okuyun. Sorularınızın çoğunun orada cevaplanacağını düşünüyorum.
Başka bir öneri, Linus Torvalds'ın Git'teki konuşması: http://www.youtube.com/watch?v=4XpnKHJAok8 . Bu diğeri de sorularınızın çoğuna cevap verebilir ve oldukça eğlenceli bir soru.
BTW, oldukça komik bulduğum bir şey: Subversion'un orijinal yaratıcılarından ikisi Brian Fitzpatrick & Ben Collins-Sussman bile, bir google konuşmasında, Subversion'un Mercurial'dan (ve genel olarak DVCS'lerden) daha düşük olduğunu ifade ederek "bunun için üzgünüm" dedi.
Şimdi, IMO ve genel olarak, takım dinamikleri herhangi bir DVCS ile daha doğal bir şekilde gelişir ve olağanüstü bir avantajı, aşağıdakileri ima ettiği için çevrimdışı işlem yapabilmenizdir:
Puanlarınız hakkında:
DVCS'lere geçiş vaaz etmek için Joomla projesine bazı belgelere katkıda bulunuyordum ve burada Merkezi vs dağıttı.
Merkezi
Genel uygulamada dağıtılmış
En sonuna dağıtılmış
Şemada hala "merkezi bir havuz" olduğunu görüyorsunuz ve bu merkezi versiyonlama hayranlarının favori argümanlarından biri: "hala merkezileşiyorsunuz" ve hayır, siz değilsiniz, çünkü "merkezileştirilmiş" depo sadece havuzdur. hepsi (örneğin resmi bir github repo) üzerinde hemfikirdir, ancak bu istediğiniz zaman değişebilir.
Şimdi, bu DVCS'leri kullanan açık kaynaklı projeler (örneğin, büyük işbirliğine sahip bir proje) için tipik iş akışıdır:
Bitbucket.org , Mercurial için bir github eşdeğeri, sınırsız alana sahip sınırsız özel depolara sahip olduklarını bilin, eğer ekibiniz beşten küçükse ücretsiz olarak kullanabilirsiniz.
Bir DVCS kullanmaya kendinizi ikna etmenin en iyi yolu bir DVCS denemektir, svn/cvs kullanan her deneyimli DVCS geliştiricisi, buna değdiğini ve onsuz zamanlarının nasıl hayatta kaldıklarını bilmediklerini söyleyecektir.
EDIT : İkinci düzenlemenizi cevaplamak için sadece bir DVCS ile farklı bir iş akışına sahip olduğunuzu tekrarlayabileceğim, neden olmamak için nedenleri aramamanızı tavsiye ederim en iyi uygulamalar nedeniyle deneyin, insanlar OOP gerekli olmadığını iddia ettiklerinde, çünkü her zaman yaptıkları şeyle karmaşık tasarım desenleri etrafında dolaşabildiklerini hissederler. paradigma XYZ; her neyse faydalanabilirsiniz.
Deneyin, "özel bir dalda" çalışmanın aslında daha iyi bir seçenek olduğunu göreceksiniz. Sonuncunun neden doğru olduğunu söyleyebilmemin bir nedeni, taahhüt etme korkusunu yitirirsiniz, formda gördüğünüz ve daha doğal bir şekilde çalıştığınız her an taahhütte bulunmanıza izin vermesidir.
"Cehennemi birleştirmek" ile ilgili olarak, "denemediğimiz sürece" diyorsunuz, "+ maintaing + aynı zamanda yenilenmiş v2.0'da aynı anda çalışıyorsanız " diyorum. Daha önce söylediğim gibi, cehennemi birleştirmek mevcut değil, çünkü:
Ayrıca, proje boyutu önemli değil, Subversion'dan geçiş yaptığımda aslında tek başına çalışırken faydaları görüyordum, her şey doğru hissediyordu. changeets (tam olarak bir düzeltme değil, bir kod eklediğiniz belirli dosyalar için belirli bir dizi değişiklik, kod tabanının durumundan izole edilmiş) ne yaptığınızı tam olarak görselleştirmenize izin verir kod tabanının tamamına değil, belirli bir dosya grubuna.
Değişiklik kümelerinin nasıl çalıştığı ve performans artışı hakkında. Vermeyi sevdiğim bir örnekle göstermeye çalışacağım: github ağ grafiği ile gösterilen svn'den mootools proje anahtarı.
Önce
Sonra
Gördüğünüz şey, geliştiricilerin, başkalarının kodunu kırma korkusu olmadan, kendi işlerine odaklanabilmeleri, itme/çekme işleminden sonra başkalarının kodunu kırmaktan endişe duyuyor (DVCS'ler: ilk taahhüt, sonra Push/pull, sonra güncelleme ) ancak burada birleştirme daha akıllı olduğundan, genellikle hiçbir zaman yapmazlar ... bir birleşme çatışması olsa bile (ki bu nadirdir), bunu düzeltmek için sadece 5 dakika veya daha az zaman harcarsınız.
Size tavsiyem Mercurial/git'in nasıl kullanılacağını bilen birini aramak ve bunu size uygulamalı olarak açıklamasını söylemektir. Mercurial'ı masaüstlerimiz ve bitbucket hesaplarımızla kullanırken komut satırında bazı arkadaşlarla yaklaşık yarım saat geçirerek onlara nasıl birleştirileceğini, hatta saçma bir sürede nasıl düzeltileceğini görmek için çatışmalar üreterek gösterebildim bir DVCS'nin gerçek gücü.
Son olarak, windows folks ile çalışıyorsanız git + github yerine Mercurial + bitbucket kullanmanızı tavsiye ederim. Mercurial da biraz daha basittir, ancak git daha karmaşık depo yönetimi için daha güçlüdür (örn. git rebase ).
Önerilen bazı ek okumalar:
Söylediğiniz şey, aslında tek bir dalda kalırsanız, dağıtılmış sürüm kontrolüne ihtiyacınız olmayan diğer şeyler arasındadır.
Bu doğrudur, ancak çalışma şekliniz için gereksiz derecede güçlü bir kısıtlama değil ve birden fazla zaman diliminde birden çok yere iyi ölçeklenmeyen bir kısıtlama değil mi? Merkezi Subversion sunucusu nerede bulunmalı ve eğer herhangi bir nedenle sunucu çöktüyse herkes eve gitmeli mi?
(teknik olarak, yasal olarak değil). Belki de bunun bittiğini düşünüyorsanız, bunun neden bu kadar büyük bir sıçrama olduğunu anlayabilirsiniz?
Benim için git'e geçişimiz hemen sonuçlandı
Bu yüzden, bittorrent'in neden ftp'den daha iyi olduğunu düşünün ve konumunuzu yeniden düşünün :)
Not: ftp'nin daha hızlı ve bittorrent'den daha fazla kullanıldığı kullanım durumları olduğu belirtilmiştir. Bu, favori düzenleyicinizin koruduğu yedekleme dosyasının bir sürüm kontrol sisteminden daha hızlı olduğu gibi doğrudur.
Dağıtılmış sürüm kontrol sistemlerinin katil özelliği dağıtılmış kısımdır. Depodan "çalışan bir kopya" teslim almazsanız, deponun tüm bir kopyasını kopyalarsınız. Güçlü faydalar sağladığı için bu çok büyük:
İnternet erişiminiz olmasa bile sürüm kontrolünün avantajlarından yararlanabilirsiniz ... Bu ne yazık ki aşırı kullanılmış ve DVCS harika bir neden olarak overhyped --- çoğumuz kurbağalar yağmur sık sık internet erişimi olmadan kendimizi kodlama bulmak gibi güçlü bir satış noktası değil.
Yerel bir depoya sahip olmanın gerçek nedeni katildir , ana depoya aktarılmadan önce işlem geçmişiniz üzerinde tam kontrole sahip olmanızdır.
Hiç bir hata düzeltildi ve şöyle bir şeyle sonuçlandı:
r321 Fixed annoying bug. r322 Argh, unexpected corner case to annoying bug in r321! r323 Ok, really fixed corner case in r322 r324 Oops, forgot to remove some debugging code related to r321 ...
Ve bunun gibi. Böyle dağınık bir tarih --- gerçekten sadece bir düzeltme vardı, ama şimdi uygulama hata ayıklama ifadelerinin eklenmesi ve kaldırılması gibi istenmeyen eserler içeren birçok taahhüt arasında yayılmıştır. SVN gibi bir sistemde, alternatif geçmişi temiz tutmak için her şey çalışana kadar (!!!) işlememektir. O zaman bile, hatalar kaybolur ve Murphy Yasası sürüm kontrolü ile önemli miktarda çalışma korunmadığında sizi acımasızca beklemektedir.
Sahip olduğunuz deponun yerel bir klonuna sahip olduğunuzda , "düzelt" ve "aykırı sürekli yuvarlayarak geçmişi yeniden yazabildiğiniz için bunu düzeltir "hata düzeltme" taahhüdünde bulunur. Günün sonunda, ana depoya aşağıdaki gibi görünen temiz bir taahhüt gönderilir:
r321 Fixed annoying bug.
Olması gereken de bu.
Tarihi yeniden yazma yeteneği, dallanma modeli ile birleştirildiğinde daha da güçlüdür. Bir geliştirici, bir dalda tamamen izole edilmiş işler yapabilir ve daha sonra bu dalı gövdeye getirmenin zamanı geldiğinde her türlü ilginç seçeneğe sahipsiniz:
Düz bir Vanilya birleştirme yapın. Her şeyi siğillere ve hepsine getirir.
Bir yeniden taban yapın. Şube geçmişini sıralamanızı, taahhütlerin sırasını yeniden düzenlemenizi, taahhütleri atmanızı, taahhütlere birlikte katılmanızı, taahhüt mesajlarını yeniden yazmanızı sağlar - hatta taahhütleri düzenleyin veya yenilerini ekleyin! Dağıtılmış bir sürüm kontrol sisteminin kod incelemesi için derin desteği vardır.
Yerel depoların, diğer programcılarımın ve gelecekteki benliğimin akıl sağlığı için tarihimi düzenlememe izin verdiğini öğrendikten sonra, SVN'yi iyilik için kapattım. Subversion istemcim artık
git svn.
Geliştiricilerin ve yöneticilerin taahhüt geçmişi üzerinde editoryal kontrol uygulamalarına izin vermek, daha iyi proje geçmişi ile sonuçlanır ve temiz bir geçmişe sahip olmak, programcı olarak üretkenliğime gerçekten yardımcı olur. "Tarihi yeniden yazma" ile ilgili tüm bu sözler sizi korkutuyorsa, merkezi, halka açık veya ana depoların ne olduğu konusunda endişelenmeyin. Tarih, birinin onu diğer insanların çektiği bir depodaki bir şubeye getirdiği noktaya kadar yeniden yazılabilir (ve olmalı!). Bu noktada tarih, taş tablete oyulmuş gibi ele alınmalıdır.
dukofgamings'in cevabı muhtemelen alabileceği kadar iyi, ama buna farklı bir yönden yaklaşmak istiyorum.
Diyelim ki söylediklerinizin kesinlikle doğru olduğunu ve iyi uygulamalar uygulayarak DVCS'nin düzeltmek için tasarlandığı sorunları önleyebileceğinizi varsayalım. Bu bir DVCS'nin size hiçbir avantaj sunmayacağı anlamına mı geliyor? İnsanlar kıyameti en iyi uygulamaları takip. İnsanlar berbat gidiyor. Öyleyse neden bir takım sorunları düzeltmek için tasarlanmış yazılımlardan kaçınarak bunun yerine insanlara yapamayacaklarını önceden tahmin edebileceğiniz bir şey yapmalarına güvenmeyi tercih edersiniz?
Evet, Subversion'da büyük taahhütleri birleştirmeniz gerektiğinde acıyor. Ancak bu aynı zamanda harika bir öğrenme deneyimidir ve çatışmaları birleştirmekten kaçınmak için mümkün olan her şeyi yapmanızı sağlar. Başka bir deyişle, sık sık check-in öğrenirsiniz. Ortak entegrasyon projeleri için erken entegrasyon çok iyi bir şeydir. Herkes bunu yaptığı sürece Subversion'u kullanmak çok sorun olmamalı.
Örneğin Git dağıtılmış işler için tasarlandı idi ve insanları kendi projelerinde çalışmaya ve daha sonra (sonunda) birleştirme için kendi çatalları oluşturmaya teşvik ediyor. OP'nin istediği “küçük ve son derece işbirlikçi ekiplere” sürekli entegrasyon için özel olarak tasarlanmış değil . Tam tersi, düşünmeye gel. Yaptığınız tek şey aynı odada birlikte çalışan aynı odada oturuyorsa, süslü dağıtılmış özellikleri için kullanmazsınız.
Bu nedenle, birlikte konumlandırılmış, CI kullanan bir ekip için, dağıtılmış bir sistem kullanırsanız ya da kullanmıyorsanız bunun çok önemli olduğunu düşünmüyorum. Bir zevk ve deneyim meselesine dayanır.
Çünkü sürekli kendi bilginize meydan okumalısınız. Subversion'a düşkünsünüz ve anlayabiliyorum çünkü yıllarca kullandım ve çok mutlu oldum, ancak bu hala size en uygun araç olduğu anlamına gelmiyor.
Ben kullanmaya başladığımda, o zaman en iyi seçim olduğuna inanıyorum. Ama zamanla başka araçlar da ortaya çıkıyor ve şimdi kendi boş zaman projelerim için bile gitmeyi tercih ediyorum.
Subversion'ın bazı eksiklikleri var. Örneğin. diskteki bir dizini yeniden adlandırırsanız, depoda yeniden adlandırılmaz. Dosya taşıma desteklenmez, bir dosya kopyalama/silme işlemini taşır ve dosyalar taşınırken/yeniden adlandırılırken birleştirme değişiklikleri yapar. Birleştirme takibi sisteme gerçekte dahil değildir, daha çok bir geçici çözüm şeklinde uygulanır.
Git bu sorunları çözer (bir dosyanın taşınmış olup olmadığını otomatik olarak algılama dahil, bunun bir gerçek olduğunu söylemenize bile gerek yoktur).
Diğer taraftan git, Subversion gibi bireysel dizin seviyelerinde dallanmanıza izin vermez.
Benim cevabım, alternatifleri araştırmanız, sizin ihtiyaçlarınıza aşina olduğunuzdan daha iyi uyup uymadığını görmeniz ve sonra karar vermeniz.
Performans açısından, bir daldan diğerine geçmeniz veya bir revizyondan diğerine atlamanız gerektiğinde Git veya başka bir DVCS'nin SVN'ye göre büyük bir avantajı vardır. Her şey yerel olarak depolandığından, işler SVN'ye göre çok daha hızlı şeklindedir.
Bu tek başına beni değiştirebilir!
Bunun yerine, "en iyi uygulamaları uygulayarak bir DVCS'ye ihtiyacınız yok" fikrine dayanmak yerine, neden SVN iş akışının bir dizi en iyi uygulama ile bir iş akışı olduğunu ve GIT/Hg iş akışının farklı bir iş akışı olduğunu düşünmüyorsunuz? farklı en iyi uygulamalar kümesi ile.
git bisect(ve ana havuzunuzdaki tüm etkileri)
Git'te çok önemli bir ilke,
git bisect. Bunu yapmak için, çalıştığı bilinen son sürümü ve başarısız olduğu bilinen ilk sürümü alırsınız ve hataya hangi taahhüde neden olduğunu bulmak için (Git'in yardımıyla) bir ikili arama gerçekleştirirsiniz. Bunu yapmak için, tüm revizyon geçmişinizin hata aramanıza müdahale edebilecek diğer hatalardan nispeten özgür olması gerekir (ister inanın ister inanmayın, bu aslında pratikte oldukça iyi çalışır ve Linux çekirdek geliştiricileri bunu her zaman yapar).
Başarmak
git bisect yeteneği, kendi özellik dalında yeni bir özellik geliştirirsiniz, yeniden adlandırır ve geçmişi temizlersiniz (böylece bilinen herhangi bir - geçmişinizdeki revizyonlar - her biri sorunu düzeltmek için sizi yarı yolda bırakan bir sürü değişiklik) ve daha sonra özellik tamamlandığında, çalışma geçmişi olan ana dalda birleştirirsiniz.
Ayrıca, bu işi yapmak için, özellik dalınızı hangi ana daldan başlattığınız hakkında bir disipline sahip olmanız gerekir.
master dalının şu anki durumundan başlayamazsınız, çünkü bununla ilgili olmayan hatalar olabilir - bu nedenle çekirdek topluluğundaki tavsiye, çekirdeğin en son kararlı sürümünden çalışmaya başlamaktır (büyük özellikler için) ) veya en son etiketli sürüm adayından çalışmaya başlamak için.
Ayrıca ara ilerlemenizi, özellik dalını bir sunucuya iterek de yedekleyebilir ve özellik dalını başka biriyle paylaşmak için bir sunucuya zorlayabilir ve özellik tamamlanmadan önce geri bildirim alabilirsiniz. kodu, projenizdeki herkesin * uğraşması gereken kod tabanının kalıcı bir özelliğine dönüştürün.
İyi uygulamalara ve iyi tasarım alışkanlıklarına sahip son derece işbirliğine dayalı bir ekipte neden teğmenlere ihtiyacımız var?
Çünkü Linux gibi projelerde, coğrafi olarak dağıtılmış o kadar çok insan var ki, konferans odasını paylaşan küçük bir ekip kadar işbirliği yapmak zor. (Microsoft Windows gibi büyük bir ürün geliştirmek için, insanların hepsi aynı binada olsalar bile, ekibin merkezi bir VCS'yi liutant olmadan çalıştıran işbirliği düzeyini sürdürmek için çok büyük olduğundan şüpheleniyorum.)
Bunları neden birlikte kullanmıyorsunuz? Mevcut projemde CVS kullanmak zorundayız. Ancak, özellik geliştirme yapmak için yerel git depolarını da saklıyoruz. Bu, her iki dünyanın imo'nun en iyisidir çünkü çeşitli çözümleri deneyebilir ve üzerinde çalıştığınız şeyin sürümlerini kendi makinenizde tutabilirsiniz. Bu, özelliğinizin önceki sürümlerine dönmenizi veya kodunuzu bozduğunuzda sorun yaşamadan çeşitli yaklaşımları denemenizi sağlar. Daha sonra merkezi bir depoya sahip olmak size merkezi bir depoya sahip olmanın avantajlarını sunar.
DVCS ile kişisel deneyimim yok, ancak buradaki yanıtlardan ve bazı bağlantılı belgelerden topladığım şeyden, DVCS ve CVCS arasındaki en temel fark kullanılan çalışma modeli.
DVCS'nin çalışma modeli, izole edilmiş geliştirme. Yeni özellik/hata düzeltmenizi, ekibin geri kalanına bırakmaya karar verene kadar diğer tüm değişikliklerden ayrı olarak geliştiriyorsunuz. O zamana kadar, istediğiniz check-in'leri yapabilirsiniz, çünkü başka hiç kimse bundan rahatsız olmayacak.
CVCS'nin çalışma modeli (özellikle Subversion) işbirlikçi gelişme yapıyor olmanızdır. Yeni özellik/hata düzeltmenizi diğer tüm ekip üyeleriyle doğrudan işbirliği içinde geliştiriyorsunuz ve tüm değişiklikler hemen herkes tarafından kullanılabilir.
svn ve
git/
hg arasındaki, değişikliklerle değişiklik kümeleri arasındaki diğer farklar rastlantısaldır. Revizyonlara dayalı bir DVCS (Subversion'da olduğu gibi) veya değişiklik kümelerine dayalı bir CVCS (Git/Mercurial'da olduğu gibi) oluşturmak çok iyidir.
Belirli bir aracı tavsiye etmeyeceğim, çünkü çoğunlukla sizin ve ekibinizin en rahat çalıştığı çalışma modeline bağlıdır.
Şahsen, bir CVCS ile çalışmakta sorunum yok.
svnhem de
git/
hg'da meydana geldiği durumlardaydı. Örneğin, bazı yazılımların V2'si V3 geliştirirken farklı bir VCS kullanarak farklı bir ekip tarafından korunuyordu. Bazen, V2 VCS'den V3 VCS'ye hata düzeltmelerinin aktarılması gerekir, bu da temel olarak V3 VCS'de çok büyük bir check-in yapmak anlamına gelir (tüm hata düzeltmeleri tek bir değişiklik kümesinde). İdeal olmadığını biliyorum, ancak farklı VCS sistemlerini kullanmak bir yönetim kararıydı.