Dağıtılmış versiyon kontrol sisteminin (DVCS) faydalarını anlamaya çalışıyorum.

Buldum Subversion'ın Yeniden eğitim ve bu yazıyı tarafından Martin Fowler çok faydalı.

Mercurial ve diğerleri DVCS, değişiklik setleri ve yerel taahhütlerle kod üzerinde çalışmanın yeni bir yolunu sunar. Cehennem ve diğer işbirliği konularını birleştirmeyi önler

Sürekli entegrasyon uyguladığımdan ve özel bir dalda yalnız çalışmak bir seçenek olmadığı için bundan etkilenmiyoruz . Her büyük sürüm için bir dal kullanıyoruz ki bu da bagajdan birleştirilen hataları düzeltiyor.

Mercurial teğmenlere sahip olmanızı sağlar

Bunun Linux gibi çok büyük projeler için faydalı olabileceğini biliyorum, 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 kopya daha hızlı günlük kaydı ve işlem yapılmasını sağlar.

Bu konuda endişeliyim, çünkü üzerinde çalıştığım çok büyük projelerde bile SVN ile hız veya alan sorunlarını fark etmedim.

Eski SVN meraklılarından kişisel deneyimlerinizi ve / veya görüşlerinizi arıyorum. Özellikle ilgili changesets kavramı ve genel performans sen ölçülen artışı.

GÜNCELLEME (12 Ocak) : Şimdi denemeye değer olduğuna ikna oldum.

GÜNCELLEME (12 Haziran) : Mercurial'ı öptüm ve çok beğendim. Vişneli yöresinin tadı kesin. Sadece denemek için Mercurial'ı öptüm. Umarım SVN Sunucum bunu umursamaz. Çok yanlış geldi. Çok doğru geldi. Bu gece aşık olduğum anlamına gelmez .

NİHAİ GÜNCELLEME (29 Temmuz) : Eric Sink'in Örnek Versiyon Kontrolü adlı yeni kitabını inceleme ayrıcalığına sahip oldum . Beni ikna etmeyi bitirdi. Mercurial'a gideceğim.

Not: Güncel soruya verilen cevap için "EDIT" bölümüne bakınız.

Her şeyden önce, Joel Spolsky tarafından Subversion Re-education okuyun . Sanırım sorularınızın çoğu orada cevaplandırılacak.

Başka bir öneri, Linus Torvalds'ın Git'teki konuşması: http://www.youtube.com/watch?v=4XpnKHJAok8 . Bu diğeri, sorularınızın çoğuna da cevap verebilir ve oldukça eğlencelidir.

BTW, oldukça komik bulduğum bir şey: orjinal subversion yaratıcılarından ikisi olan Brian Fitzpatrick ve Ben Collins-Sussman bile, bir google konuşmasında, "subversion'un mercurial (ve genel olarak DVCS'ler) inferior olduğu anlamına geldiği için üzgünüm" dedi.

Şimdi, IMO ve genel olarak, takım dinamikleri, herhangi bir DVCS ile daha doğal bir şekilde gelişiyor ve olağanüstü bir avantaj, çevrimdışı olarak çalışabilmenizdir, çünkü aşağıdakileri ima eder:

• Daha hızlı zaman anlamına gelen bir sunucuya ve bağlantıya bağlı değilsiniz.
• Sadece giriş yapabilmek için internet erişimi (veya VPN) alabileceğiniz yerlerin kölesi olmamak.
• Herkes yalnızca sunucuyu değil, her şeyi (dosyalar, tarihçe) yedekler. Yani herkes sunucu olabilir .
• Başkalarının kodunu bozmadan ihtiyaç duyuyorsanız zorunlu olarak taahhütte bulunabilirsiniz . Komisyonlar yereldir. Taahhüt ederken birbirinizin ayak parmaklarına basmıyorsunuz. Başkalarının yapısını veya çevrelerini sadece taahhüt ederek bozmazsınız.
• "Erişim izni" olmayan kişiler (DVCS’de taahhüt etmek kod yüklemek anlamına gelmediğinden) taahhüt verebilirler, katkı payını azaltıp, değişikliklerini bir bütünleştirici olarak almaya karar verebilirsiniz.
• Bir DVCS bunu zorunlu kıldığından doğal iletişimi pekiştirebilir ... yıkılmasında, yerine ne yaptığınızı, iletişimi zorlayan, ancak çalışmanızı engellediğiniz şeyleri yaparsınız.
• Katkıda bulunanlar bir araya gelerek kendi birleşmelerini gerçekleştirebilir, bu da sonuçta bütünleştiriciler için daha az iş anlamına gelir.
• Katkıda bulunanlar, başkalarını etkilemeden kendi şubelerine sahip olabilirler (ancak gerektiğinde bunları paylaşabiliyorlar).

Puanlarınız hakkında:

• DVCSland'da birleşme cehennemi yoktur; ele alınması gerekmez. Bir sonraki noktaya bakınız .
• DVCS’de, herkes bir "dalı" temsil eder, yani değişiklikler her çekildiğinde birleşme vardır. Adlandırılmış dallar başka bir şeydir.
• İsterseniz sürekli entegrasyon kullanmaya devam edebilirsiniz. Gerekli olmasa da IMHO, neden karmaşıklık ekliyor ?, testinizi kültürünüzün / politikanızın bir parçası olarak yapın.
• Mercurial bazı şeylerde daha hızlıdır, git ise bazı şeylerde daha hızlıdır. Genel olarak DVCS'lere değil, özel uygulamalarına AFAIK.
• Sadece siz değil, herkes her zaman tam projeye sahip olacak. Dağıtılan şeyin yerel olarak işlem yapabildiğiniz / güncelleyebildiğinizle ilgili olması gerekir, bilgisayarınızın dışından paylaşma / alma işlemi itme / çekme olarak adlandırılır.
• Yine, Subversion Re-education bölümünü okuyun. DVCS'ler daha kolay ve daha doğaldır, ancak farklıdırlar, cvs / svn === tüm sürümlerin temeli olduğunu düşünmeye çalışmayın.

DVCS'lere geçişin ön plana çıkmasına yardımcı olmak için Joomla projesine bazı dökümantasyonlarda katkıda bulundum ve burada merkezileştirilmiş ve dağıtılmış olanları göstermek için bazı diyagramlar çizdim .

Merkezi

Genel uygulamada dağıtılmış

Sonuna kadar dağıtılmış

Şemada gördüğünüz gibi hala bir "merkezi depo" var ve bu merkezileştirilmiş hayranların en sevdiği argümanlardan biri: "hala merkezileşiyorsun" ve hayır, "merkezileşmiş" depo sadece sen depolu olduğundan hayır hepsi hemfikirdir (örneğin resmi bir github repo), fakat bu ihtiyaç duyduğunuzda 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 biraz mercurial eşdeğeri bir github olduğunu, sınırsız alana sahip sınırsız özel depoları olduğunu biliyorum, ekibiniz beşten küçükse ücretsiz kullanabilirsiniz.

Kendinizi bir DVCS kullanmaya ikna etmenin en iyi yolu bir DVCS denemek, svn / cvs kullanan her deneyimli DVCS geliştiricisi size buna değer olduğunu ve her zaman onsuz nasıl yaşadıklarını bilmediklerini söyleyecektir.

DÜZENLEME : İkinci düzenlemenizi cevaplamak için, bir DVCS ile farklı bir iş akışına sahip olduğunuzu yineleyebilirim, en iyi uygulamalar nedeniyle denememek için neden aramamanızı tavsiye ederim , insanlar OOP olmadığını iddia ediyorlar gibi hissettiriyor. gerekli çünkü karmaşık tasarım kalıplarını XYZ paradigmasıyla her zaman yaptıkları şeyle başa çıkabiliyorlar; Yine de yararlanabilirsin.

Deneyin, "özel bir dalda" çalışmanın aslında daha iyi bir seçenek olduğunu göreceksiniz. Sonuncunun neden doğru olduğunu anlatabileceğim sebeplerden biri , uygun gördükten sonra daha doğal bir şekilde çalışıp çalışmaya başlamana izin verme korkusu kaybetmen .

"Cehennemi birleştirmek" ile ilgili olarak, "deneme yapmadıkça" diyorsunuz, " aynı anda yenilenmiş v2.0'da çalışarak + bakım yapma + çalışmayı deneseniz bile" diyorum . Daha önce de söylediğim gibi, cehennemi birleştirmek yok, çünkü:

• Taahhüt ettiğiniz her zaman adsız bir dal oluşturur ve değişiklikleriniz diğer kişilerin değişiklikleriyle her karşılaştığında, doğal bir birleşme meydana gelir.
• DVCS'ler her bir taahhüt için daha fazla meta veri topladığından, birleşme sırasında daha az çatışma ortaya çıkar ... böylece "akıllı bir birleştirme" bile diyebilirsiniz.
• Birleştirme çatışmalarına çarptığınızda, kullanabileceğiniz budur:

Ayrıca, proje büyüklüğü önemli değil, yıkılmaya başladığımda aslında tek başıma çalışırken faydaları görüyordum, her şey sadece doğru geldi. Changesets (a revizyon, ancak kod temeli durumundan izole bir taahhüt içeren belirli dosyalar için değişikliklerin belirli seti tam olarak değil), size dosyaların belirli bir gruba yaptıklarını yaparak ne demek istediğini görselleştirmek izin tüm kod tabanı değil.

Değişikliklerin nasıl işlediğiyle ve performansın artırılmasıyla ilgili olarak. Bunu vermek istediğim bir örnekle göstermeye çalışacağım: mootools projesi, github ağ grafiğinde gösterilen svn 'den proje geçişi .

Önce

Sonra

Gördüğünüz şey, geliştiricilerin, başkalarının kodlarını kırma korkusu olmadan, kendi işlerine odaklanmalarını sağlamaktır; itme / çekme işleminden sonra başkalarının kodunu kırma konusunda endişe duyuyorlar (DVCS'ler: ilk önce kabul et, sonra it / çek, ardından güncelleme ) ancak birleşme burada daha akıllı olduğu için, çoğu zaman yapmazlar ... bir birleşme çatışması olsa bile (nadir görülür), sadece 5 dakika ya da daha az bir şeyi tamir etmek için harcarsınız.

Sana tavsiyem, mercurial / git'i nasıl kullanacağını bilen birini aramak ve ona uygulamalı olarak anlatmasını söylemektir. Masaüstlerimizle ve bitbucket hesaplarımızla mercurial kullanırken bazı arkadaşlarla komut satırında yaklaşık yarım saat harcayarak, nasıl birleştirileceğini gösteren, hatta zaman zaman çok saçma bir şekilde nasıl düzelteceklerini görmek için çatışmalar üreterek gösterebildim. Onları bir DVCS'nin gerçek gücü.

Son olarak, eğer Windows millet ile çalışıyorsanız git + github yerine mercurial + bitbucket kullanmanızı öneririm. Mercurial ayrıca biraz daha basittir, ancak git daha karmaşık depo yönetimi için daha güçlüdür (örn. Git rebase ).

Bazı önerilen ek okumalar:

• Dağıtılmış Revizyon Kontrol Sistemleri: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: Lütfen Rahatlayın
• Dağıtılmış Sürüm Kontrolü ve Git [Kısım 1] ve Dağıtılmış Sürüm Kontrolü ve Git [Kısım 2]
• Git / Mercurial vs. Subversion: Savaş!
• DVCS vs Subversion smackdown, 3. turda
• Neden Mercurial'ı Git'ten Çok Seviyorum ( bölüm 1 , bölüm 2 )
• Git ile katkıda bulunmak: Git VCS ile Açık Kaynak işbirliğinin sürtünmelerini azaltmak
• “DVCS'ler şimdiye dek sizin için nasıl çalıştı?” - Joomla'da yayın! Joomla! İçin mercurial ve git deneysel olarak kabul edildikten sonra geri bildirim isteyen Çerçeve Geliştirme e-posta listesi! Platform Projesi
• DVCS dallanması (Mercurial ile) - Bu sistemlerdeki muhtemelen en önemli özellik olan DVCS'de dallamanın nasıl göründüğüne dair ayrıntılı ve örnek odaklı bir giriş

Söylediğiniz şey, aslında tek bir dalda kalırsanız, dağıtılmış sürüm denetimine gerek duymamanızdır.

Bu doğru, ancak çalışma şeklinizde gereksiz yere güçlü bir kısıtlama yok mu ve birden fazla saat diliminde birden fazla yere iyi ölçeklenemeyen biri mi? Merkezi yıkım sunucusu nerede bulunmalı ve herhangi bir nedenle kapalıysa, herkes eve gitmeli mi?

DVCSes Subversion'a, Bittorrent'in ftp'ye ne olduğunu

(teknik olarak, yasal olarak değil). Belki de bunun üzerinde düşünürseniz, neden bu kadar büyük bir sıçrama olduğunu anlayabilirsiniz.

Benim için git'e geçişimiz hemen sonuçlandı.

• Yedeklerimizin yapılması daha kolay (sadece "git uzaktan güncelleme" ve bitirdiniz)
• Merkezi depoya erişmeden çalışırken küçük adımlar atmak daha kolaydır. Siz sadece çalışırsınız ve merkezi depoyu barındıran ağa geri döndüğünüzde senkronize edilir.
• Daha hızlı Hudson inşa eder. Git çekme kullanmak için çok, çok daha hızlı güncelleme.

Öyleyse, bittorrent'in neden ftp'den daha iyi olduğunu düşünün ve konumunuzu tekrar gözden geçirin :)

Not: ftp'nin daha hızlı ve bittorrent olduğu durumlarda kullanım durumları olduğu belirtilmiştir. Bu, favori editörünüzün sakladığı yedekleme dosyasının sürüm kontrol sisteminden daha hızlı kullanılmasıyla aynı şekilde geçerlidir.

Dağıtılmış versiyon kontrol sistemlerinin katil özelliği dağıtılan kısımdır. Havuzdan "çalışan bir kopya" satın almazsınız, havuzun tamamını kopyalarsınız. Bu çok büyük, çünkü güçlü faydalar sağlıyor:

• Sürüm kontrolünün sağladığı avantajlardan yararlanabilirsiniz, örneğin internet erişimi olmasa bile ... Bu ne yazık ki fazla kullanılmıyor ve DVCS'nin harika olmasının bir nedeni olarak aşırı kullanılıyor. kendimizi kurbağanın yağmuruna başladığı sıklıkta internet erişimi olmadan kodlarken buluyoruz.

• Yerel bir depoya sahip olmanın asıl nedeni katildir, işlem geçmişiniz üzerinde ana depoya itilmeden önce tam kontrol sahibi olmanızdır .

Hiç bir hatayı düzelttim 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. Öyle bir tarih dağınık --- gerçekten sadece bir düzeltme vardı, ancak şimdi uygulama hata ayıklama ifadelerinin eklenmesi ve kaldırılması gibi istenmeyen eserler içeren birçok komisyon arasında yayılmıştır. SVN gibi bir sistemde, alternatif, geçmişi temiz tutmak için her şey çalışana kadar taahhütte bulunmak (!!!) değildir . O zaman bile, hatalar kayıyor ve Murphy Yasası, önemli miktarda çalışma sürüm kontrolü tarafından korunmadığında sizi vahşileştirmeyi bekliyor.

Sahip olduğunuz deponun yerel bir klonuna sahip olmak, bunu "düzeltmek" ve "hatalar" taahhütlerini "hata düzeltme" taahhüdünün yerine getirerek sürekli yeniden yazarak geçmişi yeniden yazabildiğiniz için düzeltir. Günün sonunda, şuna benzeyen ana depoya temiz bir taahhüt gönderilir:

r321 Fixed annoying bug.

Olması gereken bu.

Dallanma modeliyle birleştirildiğinde, tarihi yeniden yazma yeteneği daha da güçlüdür. Bir geliştirici, bir dalda tamamen izole edilmiş bir iş yapabilir ve daha sonra o dalı bagaja getirme zamanı geldiğinde, çok çeşitli ilginç seçeneklere sahip olursunuz:

• Düz bir vanilya birleştirme yapın . Siğillerdeki her şeyi ve her şeyi getirir.

• Bir rebase yap . Şube geçmişini sıralamanıza, taahhütlerin sırasını yeniden düzenlemenize, taahhütleri atmanıza, komisyonlara katılmanıza, taahhüt mesajlarını yeniden yazmanıza, hatta siparişleri düzeltmenize veya yenilerini eklemenize izin verir! Dağıtılmış bir sürüm kontrol sistemi kod incelemesi için derin bir desteğe sahiptir.

Yerel depoların, programcı arkadaşlarımın aklı başında olması ve gelecekteki benliğim adına tarihimi düzenlememe nasıl izin verdiğimi öğrendikten sonra, SVN'yi iyilik için kapattım. Subversion müşterim şimdi git svn.

Geliştiricilerin ve yöneticilerin geçmiş üzerinde taahhüt kontrolü kullanmalarına izin vermek, daha iyi proje geçmişi ile sonuçlanır ve çalışmak için temiz geçmişe sahip olmak, programcı olarak verimliliğime gerçekten yardımcı olur. Tüm bu "yeniden yazma tarihi" konusundaki konuşmaları sizi korkutuyorsa, bunun için merkezi, genel veya ana depoların ne olduğu konusunda endişelenmeyin. Tarih (ve!!), Başkalarının çektiği bir havuzda birisinin şubeye getirdiği noktaya kadar yeniden yazılabilir. Bu noktada tarih taş bir 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.

Söylediklerinizin kesinlikle doğru olduğunu ve iyi uygulamalar uygulayarak DVCS'nin düzeltmek için tasarladığı sorunları önleyebileceğinizi varsayalım. Bu, bir DVCS'nin size avantaj sağlamayacağı anlamına mı geliyor? İnsanlar en iyi uygulamaları takip etmekte zorlanırlar . İnsanlar karmakarışık olacak . Öyleyse neden bir dizi sorunu çözmek için tasarlanmış bir yazılım kullanmaktan kaçınıyorsunuz, bunun yerine insanların önceden yapamayacağı bir şeyi yapmalarını istemiyorlar.

Evet, yıkılma sürecinde büyük taahhütleri birleştirmek zorunda kaldığınızda acıtır. Fakat bu aynı zamanda mükemmel bir öğrenme deneyimidir ve çatışmaları birleştirmek için mümkün olan her şeyi yapmanıza olanak sağlar. Başka bir deyişle, sık sık check-in yapmayı öğrenirsiniz . Erken entegrasyon herhangi bir ortak proje için çok iyi bir şeydir. Herkes böyle yapıyorsa, yıkımı kullanmak çok fazla sorun olmamalı.

Örneğin Git, dağıtılmış işler için tasarlandı ve insanları kendi projeleri üzerinde çalışmaya ve daha sonra (sonunda) bir birleştirme için kendi çatallarını yaratmaya teşvik etti. O edildi değil özellikle OP istiyor ne bir "küçük ve son derece işbirlikçi ekipler" sürekli entegrasyon için tasarlanmış. Tam tersi, bir düşünün. Yaptığınız tek şey, aynı odada aynı kod üzerinde birlikte çalışarak oturuyorsanız, fantezi dağıtılmış özelliklerinden faydalanamazsınız.

Bu yüzden, ortak yerleşimli, CI kullanan bir ekip için, dağıtık bir sistem kullanıyorsanız ya da kullanmıyorsanız, bunun çok önemli olduğunu düşünmüyorum. Lezzet ve tecrübe meselesine bağlı.

Çünkü sürekli olarak kendi bilginize meydan okumalısınız. Sen yıkıma düşkün ve anlayabiliyorum çünkü yıllarca kullandım ve bu konuda çok mutlu oldum, ama bu hala sana en çok uyan araç olacağı anlamına gelmez.

Kullanmaya başladığımda o zaman en iyi seçim olduğuna inanıyorum. Ancak zaman içinde başka araçlar ortaya çıkıyor ve şimdi kendi boş zaman projelerim için bile git'i tercih ediyorum.

Ve yıkılmanın bazı eksiklikleri var. Örneğin, diskteki bir dizini yeniden adlandırırsanız, depoda yeniden adlandırılmaz. Dosya taşıma işlemi desteklenmez, bir dosyanın bir kopyalama / silme işlemi yapmasına, dosyalar taşındığında / yeniden adlandırılmasının zorlaştığında değişiklik yapılmasına neden olur. Ve birleştirme izlemesi gerçekten sisteme dahil değildir, bunun yerine 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).

Öte yandan, git, subversion gibi tek tek dizin seviyelerinde dallanmanıza izin vermez.

Bu yüzden cevabım, alternatifleri araştırmanız, gereksinimlerinize aşina olduğunuzdan daha iyi olup olmadığına bakın ve sonra karar vermelisiniz.

Performans bakımından Git'in veya herhangi bir DVCS'nin bir daldan diğerine geçmeniz veya bir revizyondan diğerine atlamanız gerektiğinde SVN'ye göre büyük bir avantajı vardır. Her şey yerel olarak depolandığından, işler SVN'den çok daha hızlı .

Bu yalnız geçiş yapmamı sağlayabilir!

"En iyi uygulamaları uygulayarak bir DVCS'ye gereksiniminiz yoktur" fikrini yerine, neden SVN iş akışının bir iş akışı, bir tane en iyi uygulama grubu ve GIT / Hg iş akışının farklı bir iş akışı olduğunu düşünmüyorsunuz? farklı en iyi uygulamalar kümesiyle.

git bisect (ve ana havuzunuzdaki tüm etkilerini)

Git'te çok önemli bir ilke kullanarak böcek bulabilirsin git bisect. Bunu yapmak için, çalıştığı bilinen en son sürümü ve başarısız olduğu bilinen ilk sürümünü ve hataya neden olanı belirlemek için (Git'in yardımı ile) koştuğunuz ilk ikili sürümü alırsınız. Bunu yapmak için, revizyon geçmişinizin tamamı, hata aramanızı engelleyebilecek diğer hatalardan bağımsız olmalıdır (ister inan ister inanma, bu aslında pratikte oldukça iyi çalışır ve Linux çekirdeği geliştiricileri bunu her zaman yapar).

git bisectYeteneği elde etmek için, kendi özellik dalında yeni bir özellik geliştirir , yeniden düzenler ve geçmişi temizlersiniz (böylece tarihinizde çalışmayan herhangi bir revizyonunuz yoktur - her birinin sizi yarı yolda bırakabileceği birçok değişiklik vardır. sorunu çözmek için), ve sonra özellik tamamlandığında, çalışma geçmişi olan ana şubeyle birleştirirsiniz.

Ayrıca, bu çalışmayı yapabilmek için, ana dalın hangi versiyonundan başlayacağınız konusunda disipline sahip olmalısınız. masterŞubenin şu anki durumundan yeni başlayamazsınız çünkü bunun ilgisiz hataları olabilir - bu yüzden çekirdek topluluğundaki tavsiye, çekirdeğin en son kararlı sürümünden çalışmaya başlamak (büyük özellikler için) veya çalışmaya başlamaktır. En son etiketli sürüm adayı.

Bu arada, özellik dalını bir sunucuya iterek aradaki ilerlemenizi yedekleyebilir ve özellik dalını bir başkasıyla paylaşmak ve özellik tamamlanmadan önce geri bildirim almak için özellik dalını bir sunucuya itebilirsiniz. kodu, projenizdeki herkesin uğraşması gereken kod tabanının kalıcı bir özelliğine dönüştürün.

Gitworkflows adam sayfası Git için tasarlanmıştır iş akışları için iyi bir giriştir. Ayrıca Git'in X'ten Daha İyi Olması Neden git iş akışlarını tartışıyor.

Büyük, dağıtılmış projeler

Neden iyi uygulamalar ve iyi tasarım alışkanlıklarına sahip, işbirliği içinde bir ekipte 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, herkes aynı binada olsalar bile, ekibin merkezi bir VCS'nin lieutanlar olmadan çalışmasını sağlayan işbirliği seviyesini sürdürmek için çok büyük olduğundan şüpheleniyorum.)

Neden onları bir arada kullanmıyorsun? Mevcut projemde CVS kullanmak zorunda kalıyoruz. Ancak, özellik geliştirme amacıyla yerel git depolarını da bulunduruyoruz. Bu, her iki dünyanın da en iyisidir çünkü çeşitli çözümleri deneyebilir ve üzerinde çalıştığınız sürümleri kendi makinenizde tutabilirsiniz. Bu, özelliğinizin önceki sürümlerine geri dönmenize veya kodunuzu bozarken sorun yaşamadan çeşitli yaklaşımlar denemenize olanak tanır. Merkezi bir depoya sahip olmak, o zaman size merkezi bir depoya sahip olmanın avantajlarını verir.

DVCS ile kişisel deneyimim yok, ancak buradaki cevaplardan ve bazı bağlantılı belgelerden topladıklarımdan DVCS ile CVCS arasındaki en temel fark kullanılan çalışma modeli.

DVCS

DVCS'nin çalışma modeli, yalıtılmış bir gelişme yapıyor olmanızdır . Yeni özelliğinizi / hata düzeltmenizi, diğer tüm değişikliklerden, ekibin geri kalanına bırakmaya karar verdiğiniz ana kadar izole ederek geliştiriyorsunuz. O zamana kadar istediğin girişleri yapabilirsin, çünkü başka kimse rahatsız olmayacak.

SVK

CVCS'nin (özellikle Subversion'un) çalışma modeli, işbirlikçi geliştirme yaptığınızdır . Yeni özelliğinizi / hata düzeltmenizi diğer tüm ekip üyeleriyle doğrudan işbirliği içinde geliştiriyorsunuz ve tüm değişiklikler herkes tarafından kullanılabilir durumda.

Diğer farklılıklar

Değişiklikler ve revizyonlar gibi svnve git/ arasındaki diğer farklar hgtesadüfidir. Revizyonlara dayanan bir DVCS (Subversion'da olduğu gibi) veya değişikliklere dayalı bir CVCS oluşturmak (Git / Mercurial'ın sahip olduğu gibi) çok iyi bir şekilde mümkün.

Herhangi bir alet önermeyeceğim, çünkü çoğunlukla sizin (ve ekibinizin) en rahat olduğu çalışma modeline bağlı.
Şahsen, CVCS ile çalışmak konusunda hiçbir sorunum yok.

• Bir şeyi kontrol etmekten korkmuyorum, çünkü eksik, ancak tamamlanabilir duruma getirme konusunda sorunum yok.
• Ben birleştirme-cehennemi yaşadı zaman, her iki durumunda meydana gelebilecek durumlarda oldu svnve git/ ' hg. Örneğin, bazı yazılımların V2'si, V3'ü geliştirirken, farklı bir VCS kullanarak farklı bir ekip tarafından korunuyordu. Zaman zaman, hata düzeltmelerinin V2 VCS'den V3 VCS'ye aktarılması gerekir; bu, temelde V3 VCS'de çok büyük bir check-in (tek bir değişiklik setinde tüm düzeltmelerin yapılması) anlamına geliyordu. Bunun ideal olmadığını biliyorum, ancak farklı VCS sistemlerini kullanmak için bir yönetim kararıydı.