SVN'yi kötü kullanmak - Mercurial cevap mı?

İşyerinde SVN kullanıyoruz, ancak sadece isim. Dallanmıyor veya birleşmiyoruz. Deponun iki kopyasını saklıyoruz, bunlardan biri bir dağıtım yaptığımızda kopyalanan ve hata düzeltmeleri için tutulan ve hemen "bunun en kısa zamanda canlı yayınlanması gerekiyor" özellik türüne sahip olan "etiket" dalı olarak hizmet veriyor. Bir kopyada yapılan değişiklikleri diğer kopyaya ("gövde") kopyalamayı unutmamalıyız. Depodaki tek bir klasörde onları bölmek yerine bir düzine projemiz var. Kısacası SVN'yi kullandığımız tek şey taahhüt edebilmek. Diğer her şey manuel olarak yapılır.

Mercurial'ı değerlendiriyorum; Git'i geçmişte kullandım (takımda DVCS kullanan tek kişi benim) ve Mercurial'ı hızlı bir şekilde alıyorum. Mercurial'ı ekibin geri kalanına bir şeyler yapmanın "daha iyi bir yolu" olarak tanıtmayı tartışıyorum çünkü dallanma çok hızlı, birleştirme çok daha kolay ve işleri yerel olarak kalbimizin içeriğine adayabilir ve sadece merkeze gönderebiliriz hazır olduklarında şube. SVN'nin tüm avantajlarından yararlanırdık (ve şu anda kimse SVN'yi gerçekten anlamadığından şu anda pek çok fayda elde etmiyoruz) artı yeni özellikler için tonlarca sürümden fazla dosyanın yüzmesine gerek yok, bu yüzden geri dönmeliysek Mahvolduk. İş akışı biraz daha basit görünüyor - sadece "Taahhüt" ün yerel olduğunu ve "Push" un SVN'nin taahhüdü gibi olduğunu hatırlamak zorundayız,

Bu iyi bir yaklaşım mı? Ekibin çok esnek olduğunu ve iş kalitemizi artıracak ve işleri nasıl kolaylaştıracağımızı söyleyecek her şeyle birlikte gideceğini unutmayın - CIO, SVN'yi potansiyeline nasıl kullanmadığımızı söylediğimde bile bana sordu " kullanabileceğimiz daha iyi bir şey var mı? " bu yüzden de onunla birlikte.

Evet.

OP'nizde "SVN" yerine "Perforce" ifadesini değiştirirseniz, mevcut işime başladığımda kendimi bulduğum duruma, hatta manuel olarak değiştirilen kopyalamaya kadar hemen hemen var. İki yıldır Mercurial'dayız ve herkes bunun büyük bir değişiklik olduğunu kabul ediyor.

KG için inanılmaz derecede yararlı olan her destek durumu için şube ve birleştirme yeteneğine ve uygun gördüğümüzde herhangi bir sayıda atılabilir şube ve depo oluşturma yeteneğine sahibiz, bu da daha sonra CI sunucumuzda oluşturabilir ve doğrulayabilir, bulut test ortamına ekleyin ve işlevselliği doğrulayın. Bu, canlı bir konuşlandırma yaptığımızda , çalışacağından neredeyse% 100 emin olduğumuz için gönül rahatlığı açısından büyük fayda sağladı (sans ortamı / DB sorunları, açıkça VCS kapsamı dışındadır).

Temel olarak, civaya geçmekten kazandığımız alan nefes almaktır. Artık bir şubenin maliyeti veya kaçınılmaz olarak takip eden korkunç birleştirme oturumları için endişelenmek zorunda değiliz, her şey çok daha kolay. Ayrıca fırın (onların barındırılan mercurial) için kravat gerçekten yararlı yani FogBugz oldukça ağır kullanın.

Hginit sitesi hakkındaki yorum , aslında çalışan bir sürüm kontrolü iş akışı için bir anahat olarak da açıktır (bunu şirketinizin özel KG iş akışı için ayarladığınızı varsayarak).

Sürüm kontrollerini hareket ettirmenin olası tek kusuru, değişimin arkasında gerçekten itici bir güç olan, konuyu okumaktan ve takımları gerçekten kullanmak istediğiniz potansiyelinden en iyi şekilde kullanmaktan mutlu olan birine ihtiyacınız olacak. yapmak.

DCVS kullanılıp kullanılmayacağına ilişkin ekip büyüklüğü ve ekip dağılımı hakkındaki yorumlara katılmıyorum. Gerçekten, CODE dağıtımı ile ilgili. Paralel olarak gerçekleşen birden fazla geliştirme döngünüz varsa, ya eski bir sistemdeki destek vakaları ya da bir grup özellik ya da yeni sistemler (ki sesinizle), DVCS kullanmaktan faydalanacaksınız.

Farklı bir araç muhtemelen sorununuzu çözmeyecek, bu makaleyi okumanız gerektiğini söyleyebilirim, en yararlı buldum:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Bence makalenin ana noktası burada özetleniyor, ancak lütfen okuyun:

Sonunda: Araçlar Hakkında Değil

Farklı kaynak kontrol sistemleriyle çalışmak ve entegre etmek için harcadığım her zaman, bir sonuca vardım: araç değil, onu nasıl kullandığınız. Bu çok hacklenmiş bir ifade, ama burada özellikle doğru görünüyor. Kaynak kodu değişikliklerini düzgün bir şekilde yönetmek için kullanıldığında - yapıların etiketlenmesi, istisna ile dallanma vb. - en ağır kaynak kontrol sistemi (* öksürük * SourceSafe * öksürük *) bile bir grup gelişigüzel işleme sahip bir Mercurial kurulumundan daha iyi performans gösterecektir ve iter.

Hayır. Teknoloji bu tür sorunları nadiren çözer.

Mercurial Subversion'dan daha karmaşıktır (evet, dallanma ve birleşme daha iyidir ve belki de daha kolaydır, ancak Subversion'un modeli Mercurial'ınkinden çok daha basittir). Subversion'u bu kadar cesur bir şekilde kullanıyorsanız, Mercurial'ı kullanabilirsiniz:

• a) Yeterli veya daha iyi
• b) Yetersiz, ancak mevcut Subversion kullanımınızdan daha iyi
• c) Şimdiye kadar olduğu gibi yetersiz
• d) Bundan daha kötü

c) ve d) en olası sonuçlara benziyor. Neden a) veya b) ile sonuçlanacağınızı düşündüğünüzü yazın.

Büyük takımların nasıl çalıştığı hakkında konuşamam, ancak küçük takımlar için bu büyük SVN sorunlarının çoğu gerçekten SVN sorunları değil ... Bunlar geliştirme sorunları. Modern geliştirme standartlarına uymuyorsanız (en önemlisi, sürekli entegrasyon yapmak), sürüm oluşturma, tanımladığınız karışıklığa dönüşür ... Yeni bir sisteme geçmeden önce, sorununuz üzerinde gerçek bir temel neden analizi yaptığınızdan emin olun. ...

Hayır. Araçlar metodolojinin yerini almaz.

Eğer varsa SCM olarak Subversion'ı kullanmayın , siz yapabilirsiniz ayrıca Mercurial kullanmayın (ve büyük olasılıkla gerçekleşecek)

SVN yapmak için ihtiyaç duyduğunuz her şeyi yapabilir ve şüpheli bir ödeme için atların orta akışını değiştirmeye gerek yoktur.

Ne yaparsanız yapın, bir güven sorununun üstesinden gelmek zorunda kalacaksınız. Birisi herkesi iş akışını değiştirmeye ikna edebilmelidir. Bu, en iyi koşullarda bile, yanınızda mantık ve gerçekleriniz olsa bile kolay değildir. Bir organizasyonda yapılması en zor şeylerden biridir. Eğer düşürürseniz veya zorlanırsa, güveni kaybedersiniz ve bu güveni yeniden kazanmak çok zor olacaktır.

İnsanların başarılı bir şekilde denediğini bildiğim birkaç şey var. Belki bunlardan biri ekibiniz için çalışacaktır:

1. Takıma bir dizi atölye çalışması için bir "koç" getirin. Bunun muhtemelen harici bir kişi olması gerekecektir (ironik olarak, birçok takımın bir yabancıya güvenmesi genellikle takımdaki birine güvenmekten daha kolaydır). İçini dışına bilen ve bu becerileri her anlayış seviyesindeki insanlara etkili bir şekilde öğretebilen ve yeni VCS'yi (*) takımın iş akışına yaymak için pragmatik bir plan tasarlayabilen biri olmalı.

2. Küçük bir yan projede yeni VCS'yi test etmek ve doğrulamak için bir "skunk-works" projesi başlatın. Yeni şeyler denemek isteyen ve bir grup başarısız deneyleri rafa atmaktan sakıncası olmayan birkaç "alfa" geliştiricisini seçin. Kokarca işler, iş akışında CONCRETE reddedilemez iyileştirmeler gösterebildiğinde, daha sonra bunu ekibin geri kalanına sunmayı deneyebilir ve bunu yapmanıza yardımcı olacak birkaç evangelistiniz olabilir.

(*) "yeni VCS" ile civa veya git anlamına gelmez, SVN de olabilir (doğru yapılır).