Birleştirme: Hg / Git ve SVN

Sık sık Hg'nin (ve Git ve ...) birleştirme işleminde SVN'den daha iyi olduğunu okudum, ancak Hg / Git'in SVN'nin başarısız olduğu (veya SVN'nin manuel müdahaleye ihtiyaç duyduğu bir yerde) birleştirilebileceği pratik örnekler görmedim. Hg / Git mutlu bir şekilde devam ederken SVN'nin nerede başarısız olacağını gösteren şube / change / commit /...- işlemlerinin birkaç adım adım listesini gönderebilir misiniz? Pratik, son derece istisnai olmayan durumlar lütfen ...

Biraz arka plan: SVN kullanan projeler üzerinde çalışan birkaç düzine geliştiricimiz var, her bir proje (veya benzer projeler grubu) kendi deposunda. Sürüm ve özellik dallarının nasıl uygulanacağını biliyoruz, bu yüzden çok sık sorunla karşılaşmıyoruz (yani, oradaydık, ancak Joel'in "tüm ekibe travmaya neden olan bir programcı" sorunlarının üstesinden gelmeyi öğrendik veya "bir kolu yeniden entegre etmek için iki hafta boyunca altı geliştiriciye ihtiyaç duyulması"). Çok kararlı olan ve yalnızca hata düzeltmeleri uygulamak için kullanılan sürüm dallarımız var. Bir hafta içinde sürüm oluşturabilecek kadar sağlam olması gereken gövdelerimiz var. Ve tek geliştiricilerin veya geliştirici gruplarının üzerinde çalışabileceği özellik dallarımız var. Evet, yeniden bütünleştirmeden sonra silinir, böylece depoyu karıştırmazlar. ;)

Bu yüzden hala Hg / Git'in SVN'ye göre avantajlarını bulmaya çalışıyorum. Biraz uygulamalı deneyim elde etmek isterim, ancak henüz Hg / Git'e taşıyabileceğimiz daha büyük projeler yok, bu yüzden sadece birkaç dosya içeren küçük yapay projelerle oynamayı bıraktım. Ve Hg / Git'in etkileyici gücünü hissedebileceğiniz birkaç vaka arıyorum, çünkü şimdiye kadar onları sık sık okudum ama kendim bulamadım.

Subversion'u kendim kullanmıyorum, ancak Subversion 1.5'in sürüm notlarından: Birleştirme izleme (temel) , birleştirme izlemenin Git veya Mercurial gibi tam DAG sürüm kontrol sistemlerinde nasıl çalıştığından aşağıdaki farklılıklar var gibi görünüyor .

• Bagajın şubeye birleştirilmesi, şubenin gövdeye birleştirilmesinden farklıdır: bir nedenle gövdeyi şubeye birleştirmek için --reintegrateseçenek gerekir svn merge.

  Git veya Mercurial gibi dağıtılmış sürüm kontrol sistemlerinde, gövde ve dal arasında teknik bir fark yoktur : tüm şubeler eşit yaratılır ( yine de sosyal fark olabilir ). Her iki yönde birleştirme aynı şekilde yapılır.

• Yeni sağlamanız gerekir -g( --use-merge-historykadar) seçeneğini svn logve svn blamedikkate birleştirme izleme almaya.

  Git ve Mercurial'da birleştirme izleme, geçmiş (günlük) ve suçlama görüntülenirken otomatik olarak dikkate alınır. Git'te ilk ebeveynin yalnızca --first-parentizleme bilgilerini "silmek" için (Mercurial için de benzer bir seçenek olduğunu düşünüyorum) takip etmeyi isteyebilirsiniz git log.

• Anladığım kadarıyla svn:mergeinfomülkiyet depoları çatışmalar hakkında yol başına bilgi (Subversion changeet-based), Git ve Mercurial ise sadece birden fazla ebeveyne sahip olabilen nesneleri işliyor.

• Subversion'da birleştirme izlemesi için "Bilinen Sorunlar" alt bölümü, yinelenen / döngüsel / yansıtıcı birleştirmenin düzgün çalışmayabileceğini gösterir. Bu, aşağıdaki geçmişlerle ikinci birleştirmenin doğru şeyi yapamayacağı anlamına gelir ('A', gövde veya şube olabilir ve 'B', sırasıyla şube veya gövde olabilir):

  * --- * --- x --- * --- y --- * --- * --- * --- M2 <- A
           \ \ /
            - * ---- M1 --- * --- * --- / <- B
  

  Yukarıdaki ASCII-art'ın kırılması durumunda: 'B' dalı 'x' revizyonunda 'A' dalından yaratılır (çatallanır), daha sonra 'A' dalı 'y' revizyonunda 'B' dalına birleştirilir. Birleştirme 'M1' ve son olarak 'B' dalı 'A' dalıyla 'M2' birleştirilir.

  * --- * --- x --- * ----- M1 - * --- * --- M2 <- A
           \ / / 
            \ - * --- y --- * --- * --- / <- B
  

  Yukarıdaki ASCII-art'ın kırılması durumunda: 'B' dalı 'x' revizyonunda 'A' dalından yaratılır (çatallanır), 'y' de 'A' dalında 'M1' olarak birleştirilir ve daha sonra tekrar 'A' dalında 'M2' olarak birleşti.

• Subversion, gelişmiş çapraz-çapraz birleştirme durumunu desteklemeyebilir .

  * --- b ----- B1 - M1 - * --- M3
       \ \ / /
        \ X /
         \ / \ /
          \ - B2 - M2 - *
  

  Git bu durumu pratikte "özyinelemeli" birleştirme stratejisini kullanarak iyi bir şekilde ele alır. Mercurial'tan emin değilim.

• In "Bilinen Sorunlar" bir tarafı (eski adıyla) adlandırma olmadan dosya (ve belki de değiştirir o) ve ikinci yan değiştirir dosyayı yeniden adlandırır dosya yeniden adlandırır, örneğin ile migh değil işi izleme o birleştirme orada uyarıyor.

  Hem Git hem de Mercurial bu durumda pratikte iyi işler: Yeniden adlandırma algılamayı kullanan Git, yeniden adlandırma izlemeyi kullanan Mercurial .

HTH

Ben de Subversion'un bir dalı birleştiremediği ve Mercurial'ın (ve Git, Bazaar, ...) doğru olanı yaptığı bir durum arıyordum.

SVN Kitabı , yeniden adlandırılan dosyaların nasıl yanlış birleştirileceğini açıklar . Bu, Subversion 1.5 , 1.6 , 1.7 ve 1.8 için geçerlidir ! Aşağıdaki durumu yeniden oluşturmaya çalıştım:

cd / tmp
rm - rf svn - repo svn - ödeme
svnadmin svn oluştur - repo
svn ödeme dosyası : /// tmp / svn - repo svn - ödeme
cd svn - ödeme
mkdir gövde dalları
echo 'Güle güle, Dünya!' > gövde / merhaba . Txt
svn gövde dalları ekleyin
svn commit - m 'İlk içe aktarma.' 
svn copy '^ / trunk' '^ / branch / rename' - m 'Şube oluştur.' 
svn anahtarı '^ / trunk' . 
echo 'Merhaba Dünya!' > merhaba . Txt    
svn commit - m 'Bagajda güncelleme.' 
svn anahtarı '^ / branch / rename' . 
svn merhaba yeniden adlandırın . txt merhaba . en . Txt 
svn commit - m 'Dalda yeniden adlandır.' 
svn anahtarı '^ / trunk' . 
svn merge - '^ / branch / rename' ifadesini yeniden bütünleştirin 

Kitaba göre, birleştirme temiz bir şekilde bitmeli, ancak güncelleme trunkunutulduğundan yeniden adlandırılan dosyada yanlış veriler var . Bunun yerine bir ağaç çatışması alıyorum (Subversion 1.6.17, Debian'ın en yeni sürümü ile yazılırken):

--- Havuz URL'leri arasındaki farkları '.' İle birleştirmek:
Merhaba.en.txt
   C merhaba.txt
Çatışmaların özeti:
  Ağaç çatışmaları: 1

Hiç bir çakışma olmamalıdır - güncelleme dosyanın yeni adıyla birleştirilmelidir. Subversion başarısız olsa da, Mercurial bunu doğru bir şekilde ele alır:

rm -rf /tmp/hg-repo
hg init /tmp/hg-repo
cd /tmp/hg-repo
echo 'Goodbye, World!' > hello.txt
hg add hello.txt
hg commit -m 'Initial import.'
echo 'Hello, World!' > hello.txt
hg commit -m 'Update.'
hg update 0
hg rename hello.txt hello.en.txt
hg commit -m 'Rename.'
hg merge

Birleştirme işleminden önce, depo şöyle görünür hg glog:

@ değişiklik seti: 2: 6502899164cc
| etiket: ipucu
| ebeveyn: 0: d08bcebadd9e
| kullanıcı: Martin Geisler
| Tarih: Perş 01 Nis 12:29:19 2010 +0200
| özet: Yeniden adlandırın.
|
| o değişiklik kümesi: 1: 9d06fa155634
| / kullanıcı: Martin Geisler 
| Tarih: Perş 01 Nis 12:29:18 2010 +0200
| özet: Güncelleme.
|
o değişiklik kümesi: 0: d08bcebadd9e
   kullanıcı: Martin Geisler 
   Tarih: Perş 01 Nis 12:29:18 2010 +0200
   özet: İlk içe aktarma.

Birleştirmenin çıktısı:

hello.en.txt ve hello.txt dosyalarını hello.en.txt ile birleştirme
0 dosya güncellendi, 1 dosya birleştirildi, 0 dosya kaldırıldı, 0 dosya çözülmedi
(şube birleşmesi, taahhüt etmeyi unutmayın)

Başka bir deyişle: Mercurial, değişikliği düzeltme 1'den aldı ve düzeltme 2'den ( hello.en.txt) yeni dosya adıyla birleştirdi . Yeniden düzenlemeyi desteklemek için bu vakanın ele alınması elbette önemlidir ve yeniden düzenleme tam olarak bir dalda yapmak isteyeceğiniz bir şeydir.

Her zamanki avantajlardan bahsetmeden (çevrimdışı taahhütler, yayın süreci , ...) burada sevdiğim bir "birleştirme" örneği:

Görmeye devam ettiğim ana senaryo, üzerinde ... iki ilgisiz görevin gerçekten geliştirildiği bir branştır
(bir özellikten başladı, ancak bu diğer özelliğin geliştirilmesine yol
açar.Ya da bir yamadan başlar, ancak başka bir özelliğin geliştirilmesi).

Ana daldaki iki özellikten yalnızca birini nasıl birleştirirsiniz?
Veya kendi dallarındaki iki özelliği nasıl ayırıyorsunuz?

Bir tür yamalar oluşturmayı deneyebilirsiniz, bununla ilgili sorun, artık arasında olabilecek işlevsel bağımlılıklardan emin değilsiniz :

• yamalarınızda kullanılan taahhütler (veya SVN için düzeltme)
• diğeri yamanın parçası değil

Git (ve sanırım Mercurial da) bir dalın rebase --onto (dalın kökünü sıfırlamak) seçeneği öneriyoruz:

Gönderen Jefromi gönderide

- x - x - x (v2) - x - x - x (v2.1)
           \
            x - x - x (v2-only) - x - x - x (wss)

v2 için yamalar ve bu durumda yeni bir wss özelliği bulunan bu durumu çözebilirsiniz:

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - x - x (v2-only)
           \
             x - x - x (wss)

, şunları yapmanızı sağlar:

• her dalın istendiği gibi derlendiğini / çalışıp çalışmadığını kontrol etmek için her bir dalı ayrı ayrı test edin
• sadece ana yapmak istediğiniz şeyi birleştirin.

Sevdiğim diğer özellik (birleşmeleri etkileyen) taahhütleri ezme yeteneğidir (henüz başka bir repoya itilmemiş bir dalda) :

• daha temiz bir tarih
• daha tutarlı taahhütler (fonksiyon1 için taahhüt1 yerine, fonksiyon2 için taahhüt2 yerine, fonksiyon1 için tekrar taahhüt3 ...)

Bu, daha az çatışma ile çok daha kolay birleştirme sağlar.

Kısa bir süre önce SVN'den GIT'e geçtik ve aynı belirsizlikle karşılaştık. GIT'in daha iyi olduğuna dair birçok anekdot kanıtı vardı, ancak herhangi bir örnekle karşılaşmak zordu.

Yine de size söyleyebilirim ki, GIT, birleşmede SVN'den çok daha iyi. Bu açıkça anekdottur, ancak takip edilmesi gereken bir tablo var.

Bulduğumuz şeylerden bazıları:

• SVN, olması gerektiği gibi görünen durumlarda çok fazla ağaç çatışması fırlatırdı. Bunun dibine hiç ulaşmadık, ancak GIT'de gerçekleşmiyor.
• Daha iyi olsa da, GIT önemli ölçüde daha karmaşıktır. Antrenmana biraz zaman ayırın.
• Biz sevdim Tortoise SVN, alışmıştık. Tortoise GIT o kadar iyi değil ve bu sizi rahatsız edebilir. Ancak şimdi Tortoise SVN veya GIT GUI'lerden herhangi birini tercih ettiğim GIT komut satırını kullanıyorum.

GIT'i değerlendirirken aşağıdaki testleri yaptık. Bunlar, GIT'i birleştirme söz konusu olduğunda kazanan olarak gösterir, ancak o kadar değil. Pratikte fark çok daha büyük, ancak sanırım SVN'nin kötü işlediği durumları tekrarlamayı başaramadık.

Diğerleri bunun daha teorik yönlerini ele aldı. Belki daha pratik bir bakış açısı verebilirim.

Şu anda bir "özellik şube" geliştirme modelinde SVN kullanan bir şirket için çalışıyorum. Yani:

• Bagajda hiçbir iş yapılamaz
• Her geliştirici kendi dalını oluşturabilir
• Şubeler, üstlenilen görev süresince devam etmelidir
• Her görevin kendi şubesi olmalı
• Bagaja birleştirmeye izin verilmelidir (normalde bugzilla ile)
• Yüksek düzeyde kontrol gerektiğinde, bir bekçi tarafından birleştirme yapılabilir

Genel olarak çalışır. SVN böyle bir akış için kullanılabilir, ancak mükemmel değildir. SVN'nin insan davranışını engelleyen ve şekillendiren bazı yönleri vardır. Bu ona bazı olumsuz yönler verir.

• Daha düşük noktalardan dallanan insanlarla ilgili birkaç sorun yaşadık ^/trunk . Bu altlık, ağaçtaki bilgi kayıtlarını birleştirir ve sonunda birleştirme izlemesini keser. Yanlış çatışmalar ortaya çıkmaya başlar ve karışıklık hüküm sürer.
• Bagajdaki değişiklikleri bir şubeye almak nispeten düzdür. svn mergene istersen yapar. Değişikliklerinizin birleştirilmesi için --reintegratebirleştirme komutunun olması gerekir (bize söylenir) . Bu anahtarı asla tam olarak anlamadım, ancak bu, dalın tekrar gövdeye birleştirilemeyeceği anlamına geliyor. Bu, ölü bir dal olduğu ve çalışmaya devam etmek için yeni bir dal oluşturmanız gerektiği anlamına gelir. (Notu gör)
• Şube oluştururken ve silerken sunucuda URL'ler aracılığıyla işlem yapma işi gerçekten insanları şaşırtır ve korkutur. Yani bundan kaçınırlar.
• Dallar arasında geçiş yapmak yanlıştır, bir ağacın bir kısmını A dalına bakarken, bir başka parçayı B dalına bakarken bırakırlar. Böylece insanlar tüm işlerini bir dalda yapmayı tercih ederler.

Gerçekleşme eğilimi, bir mühendisin 1. günde bir şube oluşturmasıdır. İşine başlar ve bunu unutur. Bir süre sonra bir patron gelir ve işini bagaja bırakıp bırakamayacağını sorar. Mühendis bugün yeniden hayal kurmanın anlamı:

• Uzun ömürlü dalını yeniden gövdeye dönüştürmek ve tüm çatışmaları çözmek ve ayrı bir dalda olması gereken, ancak olmayan ilgili olmayan kodu serbest bırakmak.
• Şubesini silme
• Yeni bir şube oluşturma
• Çalışma kopyasını yeni şubeye değiştirme

... ve mühendis bunu olabildiğince az yaptığından, her adımı yapmak için "sihirli büyüyü" hatırlayamazlar. Yanlış anahtarlar ve URL'ler olur ve birdenbire karmaşa içinde olurlar ve "uzman" a giderler.

Sonunda her şey yerleşir ve insanlar eksikliklerle nasıl başa çıkacaklarını öğrenir, ancak her yeni marş aynı problemlerden geçer. Nihai gerçeklik (başlangıçta belirlediğim şeyin aksine):

• Bagajda iş yapılmaz
• Her geliştiricinin bir ana dalı vardır
• Şubeler işin serbest bırakılması gerekene kadar sürer
• Biletli hata düzeltmeleri kendi şubelerini alma eğilimindedir
• Bagaja birleştirmeler yetkilendirildiğinde yapılır

...fakat...

• Bazen iş, başka bir şeyle aynı dalda olduğu için yapmaması gerektiğinde gövdeyi yapar.
• İnsanlar tüm birleştirmelerden (kolay şeyler bile) kaçınırlar, bu yüzden insanlar genellikle kendi küçük baloncuklarında çalışırlar
• Büyük birleşmeler meydana gelir ve sınırlı miktarda kaosa neden olur.

Neyse ki takım baş edebilecek kadar küçük, ama ölçeklenmeyecekti. Şey, bunların hiçbiri CVCS ile ilgili bir sorun değildir, ancak daha fazlası, birleşme DVCS'deki kadar önemli olmadığı için kaygan değildirler. Bu "birleştirme sürtünmesi", "Özellik Dal" modelinin bozulmaya başladığı anlamına gelen davranışa neden olur. İyi birleşmelerin yalnızca DVCS'nin değil tüm VCS'nin bir özelliği olması gerekir.

Göre bu orada şimdi nerede --record-onlyçözmek için kullanılabilecek anahtar --reintegratesorunu ve görünüşe otomatik bir yeniden uyum yapmak v1.8 seçer ve şube sonradan ölü olarak neden olmaz

Subversiyon 1.5'ten önce (yanılmıyorsam) subversion, birleştirme geçmişini hatırlamaması açısından önemli bir dezavantaja sahipti.

VonC tarafından özetlenen davaya bakalım:

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - A - x (v2-only)
           \
             x - B - x (wss)

A ve B düzeltmelerine dikkat edin. "Wss" dalındaki A düzeltmesinden B revizyonundaki "yalnızca v2" dalına (her ne nedenle olursa olsun) değişiklikleri birleştirdiğinizi, ancak her iki dalı da kullanmaya devam ettiğinizi varsayalım. İki dalı tekrar civa kullanarak birleştirmeye çalışırsanız, yalnızca A ve B revizyonlarından sonra değişiklikleri birleştirirsiniz. Yıkım ile her şeyi, daha önce birleştirme yapmamış gibi birleştirmelisiniz.

Bu, kendi deneyimimden bir örnek, kodun hacmi nedeniyle B'den A'ya birleştirmenin birkaç saat sürdüğü bir örnek: bu, tekrardan geçmek için gerçek bir acı olurdu ve bu, 1.5 öncesi yıkım için geçerli olurdu.

Hginit'ten birleştirme davranışında bir diğer, muhtemelen daha alakalı bir fark: Yıkım Yeniden Eğitimi :

Siz ve ben bazı kodlar üzerinde çalıştığımızı ve bu kodu şubelediğimizi ve her birimizin ayrı çalışma alanlarımıza girip bu kodda ayrı ayrı çok sayıda değişiklik yaptığımızı ve bu yüzden biraz farklılaştıklarını düşünün.

Birleştirmemiz gerektiğinde, Subversion her iki revizyona da - değiştirilmiş koduma ve değiştirilmiş kodunuza - bakmaya çalışır ve bunları büyük bir kutsal olmayan karmaşada nasıl parçalayacağınızı tahmin etmeye çalışır. Genellikle başarısız olur, sayfalar ve gerçekten çatışma olmayan “birleşme çatışmaları” sayfaları üretir, sadece Subversion'un ne yaptığımızı anlayamadığı yerler.

Aksine, Mercurial'ta ayrı ayrı çalışırken, Mercurial bir dizi değişiklik kümesini tutmakla meşguldü. Ve böylece, kodumuzu birleştirmek istediğimizde, Mercurial aslında çok daha fazla bilgiye sahip: sadece nihai ürüne bakmak ve nasıl koyacağımızı tahmin etmek yerine her birimizin neyi değiştirdiğini ve bu değişiklikleri yeniden uygulayabildiğimizi biliyor birlikte.

Kısacası, Mercurial'ın farklılıkları analiz etme biçimi yıkımdan daha üstündür.