Biz Subversion Geeks'iz ve Mercurial'ın faydalarını bilmek istiyoruz [kapalı]

Okudum ben bir Subversion geek'im, neden Mercurial, Git veya başka bir DVCS'yi göz önünde bulundurmalıyım .

İlgili bir takip sorum var. Bu soruyu okudum ve önerilen linkleri ve videoları okudum ve faydalarını görüyorum ama insanların hakkında konuştukları genel zihinsel düşünceleri göremiyorum.

Ekibimiz 60 projeden oluşan büyük bir kod tabanlı çalışan 8-10 geliştiricidir. Subversion kullanıyoruz ve ana bir bagajımız var. Bir geliştirici yeni bir Fogbugz vakası başlattığında, bir svn dalı oluştururlar, dalda işi yaparlar ve bittiğinde gövdeye geri dönerler. Zaman zaman şubede uzun süre kalabilirler ve değişiklikleri almak için gövdeyi şubeyle birleştirebilirler.

Linus'un bir şube yaratıp tekrar yapamayan insanlar hakkında konuşmasını izlediğimde, bu biz değiliz. Muhtemelen haftada 50-100 şube açıyoruz. En büyük zorluk birleşme ama biz de bu konuda oldukça başarılı olduk. Şube kökü yerine sisbugz davası & check-in ile birleşme eğilimindeyim.

Hiçbir zaman uzaktan çalışmaz ve şubelerden asla dal ayırmayız. Kod tabanının bu bölümünde çalışan tek kişi sizseniz, bagajla birleştirme sorunsuz gider. Başka biri aynı kod bölümünü değiştirmişse, birleştirme dağınık hale gelebilir ve biraz ameliyat yapmanız gerekebilir. Çatışmalar çatışıyor, kodu anlayacak kadar akıllı olmadıkça, herhangi bir sistemin çoğu zaman bunu nasıl doğru yapabileceğini anlamıyorum.

Bir dal oluşturduktan sonra 60k + dosyalarının takibi biraz zaman alır ancak bu, kullandığımız herhangi bir kaynak kontrol sisteminde sorun olabilir.

Bizim için çok yardımcı olacağını görmediğimiz herhangi bir DVCS'nin bir faydası var mı?

Sorunuzu tekrarlamak için, "Yalnızca DVCS'yi merkezi bir şekilde kullanmayı planlıyorsak, bunun yararları nedir?" Bu şekilde sorduğun zaman sormaz. VCS'de görev başına bir dal çok yaygındır. Bunu düşünürseniz, bir gün için gövdeden bağımsız olarak değişen bir geliştiricinin makinesinde kaynak kodun yerel bir çalışma kopyasına sahip olması, hiç kimse bunu söylemese bile bir daldır. Bununla iş akışınız arasındaki tek fark, bu şubelere merkezi sunucuda da kalıcı bir isim vermenizdir. Bu Linus ve diğerlerinin hakkında konuştuğu türden bir dallanma değil.

DVCS'yi anlamak, düşünmede temel bir değişiklik gerektirir. Kendinize, istediğiniz kişiyle paylaşılan, dilediğiniz sayıda şubeyle ne yapacağınızı ve sadece onlarla ne yapabileceğinizi sormalısınız. Bu, sadece kendiniz tarafından görülen dalları içerir.

İmkanlar sonsuzdur. Sadece bir örnek için, bir arayüzün diğer tarafında çalışan iki kişi nasıl olur? Düzenli olarak kod paylaşmaları gerekiyor, ancak henüz herkesle paylaşacak kadar kararlı değil. Kendi aralarında paylaşacakları bir dal oluşturabilir, sonra hazır olduklarında tekrar merkezi depoya birleştirebilirler.

Orta düzeyde yerel taahhütlerde bulunabilme becerisi hepsine kendi başına değer. Bu sadece kendin için deneyimlemek zorundasın.

Repo'nuzun yerel olması ile kazanılan hız, hepsine de tek başına değer. Evet, ilk klon 60k dosya deposu için herhangi bir VCS'de kaçınılmaz olarak yavaş olacaktır, ancak bir kere sahip olduğunuzda, yeni bir dalı kontrol etmek bir DVCS ile daha hızlıdır.

Özel durumunuz için DVCS'ye geçmenin bir faydası yok. Mevcut sisteminizden memnunsunuz, ihtiyacınız olan her şeyi yapıyor, neden geçiş yapmalısınız? SVN hala aktif bir Açık Kaynak projesidir ve tüm büyük IDE'ler ve geliştirme araçları ile hg veya git'ten daha iyi, daha olgun entegrasyonlara sahiptir. Ekibinizin büyüklüğü ve proje sayısı göz önüne alındığında, mevcut durumun iyi çalışması için gerçekten yeni bir araca geçmek için zaman ayırmak ister misiniz?

DVCS olmadan çalışamayan geliştiricilere sahipseniz, onları hg veya git için svn ağ geçitlerine yönlendirin. Onlara svn deposundaki girişlerinin, ekibin geri kalanının kullandığı her türlü prosedür ve işlemi yerine getirmesi gerektiğine açıkça dikkat edin. Bu yaklaşımın bir başka avantajı, geçitleri zaten kullandığını söylemeden gerçek DVCS zealotlarının artık dolaptan çıkabileceğini söylemektir.

Bana göre zaten birçok insanın DVCS kullanmaya başladıktan sonra benimsemiş olduğu iş akışına çok benzeyen bir iş akışı kullanıyorsunuz.

Sizce, bir DVCS, SVN'ye göre aşağıdaki önemli avantajlara sahip olacaktır:

• Repolarınızı kopyaladığınızda yerel olarak birçok işlem yapılabilir.
  • Depo günlüğüne bakmak svn sunucusuna dokunmak zorunda değildir, bu yüzden inanılmaz derecede hızlı olabilir.
  • Benzer şekilde, dalları değiştirmek sunucuya erişim gerektirmez, yerel klonlar da gerektirmez.
• Şubeler tarih boyunca birbirinden ayrı yollar olduğundan, havuzunuz, herkesin oluşturduğu her dalda dağınık değildir (yalnızca gerçekten SVN'de yayın şubeleri vardır, ancak branchesdizinin hala ilgili olmayan birçok alt dizini vardır).
  • Git'te, bir dal tekrar birleştirilip ref silindiğinde, orada bile olduğunu asla bilemezsiniz.
  • Mercurial size seçim var ya (ki bu durumda o ebediyen her Changeset içine kodlanmış oluyor) bir şube adlandırma ya da sadece sessizce edecek isimsiz (topolojik) şube oluşturma birleştirme o zaman tarihe mergeiçine d arka default( trunk)
• SVN'de şubelerin dalları yararlı olamayacak kadar belirsizdir. İçinde gitve hgonlar sadece kurs için eşit.
• DVCS'nin yazılım geliştirmenin bir DAG olduğunu , yani birleştiğinizde, birden fazla ebeveyni olan bir değişiklik setiyle sonuçlandığını anlayın . SVN (en azından kullandığım sürüm) bunu gerçekten anlamıyor.

Bu son noktada, diyorsun ki

Çatışmalar çatışıyor, herhangi bir sistemin, kodu anlayacak kadar akıllı olmadığı sürece nasıl doğru bir şekilde elde edebileceğini anlamıyorum.

Kullanarak geçiş olarak hgkullanarak münhasıran svntek başına ve daha sonra gitsvnda birleştirmeleri olması benim deneyim oldu çok serbest basit ve sorunsuz hgve gitsvnonlar ile olduğundan daha svn. İle birleşmeler svn(en azından kullandığımız sürüm), manuel olarak çözülmesi gereken önemli ölçüde daha fazla çakışma oluşturur.

Birleşmelerin SVN'de daha zor olmasının nedenlerinden biri, farklı olan her satır için yalnızca iki seçenek sunmasıdır.

• Birleştirdiğiniz daldaki metin
• dalda birleştirdiğiniz metin

DVCS’den gelen birleşimler tipik olarak size üçüncü bir seçenek

• Birleştirdiğiniz her iki dalın ortak atalarından gelen metin

Bunun ne kadar yararlı olduğunu hafife almayın, size değişiklikler için basit bir iki yönlü farkın sağlayabileceğinden çok daha iyi bir bağlam sağlar.

Sonuçta, denemenizi öneririm. Gibi araçlar sayesinde gitsvnve hgsubversion, hatta mevcut SVN repo ile onları deneyebilirsiniz .

^{Klonu ilk başta oluşturmak kraliyet PItA'sıdır, ancak bunu bir kez yaptıktan sonra, mevcut CVCS'nizle birlikte bir DVCS'nin gücünden faydalanırsınız.}

Böyle bir geçişten sonra fark ettiğim önemli bir değişiklik var: Şubeleri çok daha sık değiştiriyorum ve Subversion ile karşılayabileceğimden daha sık bağlıyorum. Örneğin, bir dizi halinde düzenlenmiş çok sayıda küçük işlevsellik dalı vardır ve her birine bit ekleyerek ayları harcayabilirim, hepsini sürekli değişen bir gövdeye sırayla yeniden dizebilirim. İşlevsellik dallarının birleştirildiği sıranın yeniden düzenlenmesi önemsizdir.

Ama aslında, aslında Subversion'dan uzaklaşmadım. Sadece yerel svn müşterim olarak git kullanıyorum.