9.2 Git ve Diğer Sistemler - Git’e Geçiş

git svn kullanımıyla ilgili önceki bölümü okuduysanız, bir repoyu svn ile kopyalamak (git svn clone) için bu talimatları kolayca kullanabilirsiniz: Sonra Subversion sunucusunu durdurup, yeni bir Git sunucusuna itin ve onu kullanmaya başlayın. Geçmişi istiyorsanız, bunu Subversion sunucusundan verileri çektiğiniz kadar hızlı bir şekilde gerçekleştirebilirsiniz (bu biraz zaman alabilir).

Ancak içe aktarma tamamen mükemmel değildir; çok uzun süreceği için bunu doğru yapsanız iyi olur. İlk sorun yazar bilgisidir. Subversion’da katkıda bulunan her kişinin sistemde katkı bilgilerinde kayıtlı bir kullanıcısı vardır. Önceki bölümdeki örneklerde, blame çıktısı ve git svn log gibi bazı yerlerde schacon gösterilmektedir. Bunu daha iyi Git yazar verileriyle eşleştirmek istiyorsanız, Subversion kullanıcılarından Git yazarlarına bir eşleştirmeye ihtiyacınız vardır. Bu eşlemeyi şu şekilde içeren users.txt adlı bir dosya oluşturun:

SVN’nin kullandığı yazar adlarının bir listesini almak için şunu çalıştırabilirsiniz:

Bu komut dizini günlük (log) çıktısını XML biçiminde oluşturur, ardından yalnızca yazar bilgilerinin bulunduğu satırları tutar, yinelenenleri atar ve XML etiketlerini çıkarır (Bariz şekilde, bu yalnızca grep, sort ve Perl yüklü bir makinede çalışır.) Ardından, her girişin yanına eşdeğer Git kullanıcı verilerini ekleyebilmeniz için bu çıktıyı users.txt dosyanıza yönlendirin.

Yazar verilerini daha doğru bir şekilde eşleştirmesine yardımcı olmak için bu dosyayı git svn 'ye sağlayabilirsiniz. Ayrıca, clone veya init komutuna --no-metadata seçeneğini ileterek, git svn 'ye Subversion’ın normalde içe aktardığı meta verileri eklememesini de söyleyebilirsiniz (ancak senkronizasyon meta verilerini korumak istiyorsanız, bu parametreyi atlamakta özgürsünüz). Bu, import komutunuzun şu şekilde görünmesini sağlar:

Artık my_project dizininizde daha güzel bir Subversion içe aktarımına sahip olmalısınız. Buna benzeyen katkılar yerine

şunun gibi:

Yazar alanı çok daha iyi görünmekle kalmıyor, aynı zamanda git-svn-id de artık orada değil.

Ayrıca biraz içe aktarma sonrası temizlik de yapmalısınız. Bunlardan biri git svn 'nin oluşturduğu tuhaf referansları temizlemektir. Öncelikle etiketleri, tuhaf uzak dallar yerine gerçek etiketler olacak şekilde, ve ardından geri kalan dalları da yerel olacak şekilde taşıyacaksınız.

Etiketleri uygun Git etiketleri olacak şekilde taşımak için şunu çalıştırın:

Bu, refs/remotes/tags/ ile başlayan uzak dal referanslarını alır ve onları gerçek (hafif) etiketler haline getirir.

Ardından, referansların geri kalanını refs/remotes altında yerel şubelere taşıyın:

Subversion’da yalnızca bir dal görürken, sonuna @xxx (burada xxx bir sayıdır) eklenmiş bazı ekstra dallar görebilirsiniz. Bu aslında ``peg-revizyonlar`` adı verilen bir Subversion özelliğidir ve Git’te sözdizimsel karşılığı olmayan bir şeydir. Bu nedenle git svn, svn sürüm numarasını dal adına ekler (tıpkı o dalın sabit revizyonunu ele almak için svn’de yazdığınız gibi) . Artık sabit düzeltmeleri umursamıyorsanız, bunları kaldırmanız yeterlidir:

Artık tüm eski dallar gerçek Git dalları ve tüm eski etiketler gerçek Git etiketleridir.

Temizlenecek son bir şey daha var. Ne yazık ki, git svn Subversion’un varsayılan dalına eşlenen trunk adında fazladan bir dal oluşturur, ancak trunk ref’i, master ile aynı yeri işaret eder. master kelimesi Git’e daha uyggun bir ifade biçimi olduğundan, fazladan dalın nasıl kaldırılacağı aşağıda açıklanmıştır:

Yapılacak son şey, yeni Git sunucunuzu uzak olarak eklemek ve ona itmektir. Sunucunuzu uzak olarak eklemenin bir örneği:

Tüm dallarınızın ve etiketlerinizin üste çıkmasını istediğiniz için artık şunu çalıştırabilirsiniz:

Artık tüm dal ve etiketleriniz güzel ve temiz bir içe aktarma işlemiyle yeni Git sunucunuzda olmalıdır.

Mercurial ve Git’in sürümleri temsil etme modelleri çok benzer olduğundan ve Git biraz daha esnek olduğundan; bir repoyu Mercurial’den Git’e dönüştürmek oldukça basittir. Bu dönüşüm için hg-fast-export adlı bir araca ihtiyacınız olacak.

Dönüşümün ilk adımı, dönüştürmek istediğiniz Mercurial reposunun tam kopyasını almaktır:

Bir sonraki adım, bir yazar eşleştirme dosyası oluşturmaktır. Değişiklik setlerindeki yazar alanına koyabileceği şeyler konusunda Mercurial, Git’ten biraz daha esnek olduğu için; temizlemek için bu iyi bir zamandır. Bunu yapmak için bir bash shell’inde tek satırlık bir komut kullanabilirsiniz:

Bu projenizin geçmişinin ne kadar uzun olduğuna bağlı olarak birkaç saniye sürecektir ve sonrasında /tmp/authors dosyası şöyle görünecektir:

Bu örnekte, aynı kişi (Bob), dört farklı ad altında değişiklik setleri oluşturmuştur; bunlardan biri Git katkısı için doğru görünürken, biri tamamen geçersiz olacaktır. Hg-fast-export her bir satırı bir kurala dönüştürerek bunu düzeltmemize izin verir: "<input>"="<output>", bir <giriş> 'i bir <çıkış> 'a eşleyen bir kural. <giriş> ve <çıkış> dizelerinin içinde, python string_escape kodlaması tarafından anlaşılan tüm kaçış dizileri desteklenir. Eğer yazar eşleştirme dosyası eşleşen bir <input> içermiyorsa, bu yazar Git’e değiştirilmeden gönderilecektir. Eğer tüm kullanıcı adları uygun görünüyorsa, bu dosyaya hiç ihtiyacımız olmayacaktır. Bu örnekte, dosyamızın şu şekilde görünmesini istiyoruz:

Aynı türdeki eşleştirme dosyası, Mercurial adı Git tarafından izin verilmediğinde dalları ve etiketleri yeniden adlandırmak için de kullanılabilir.

Bir sonraki adım, yeni Git reposunu oluşturmak ve dışa aktarma komut dosyasını çalıştırmaktır:

-r bayrağı, dönüştürmek istediğimiz Mercurial reposunu bulması için hg-fast-export’a nerede bakacağını ve -A bayrağı da yazar eşleştirme dosyasını nerede bulacağını söyler (dallar ve etiket eşleştirme dosyaları sırasıyla -B ve -T bayrakları ile belirtilir). Betik Mercurial değişiklik setlerini ayrıştırır ve bunları Git’in "fast-import" özelliği için bir betiğe dönüştürür (bu özelliği biraz sonra detaylı bir şekilde inceleyeceğiz). Bu biraz zaman alır (ancak ağ üzerinden yapılmasından çok daha hızlıdır) ancak çıktı oldukça ayrıntılıdır:

İşte hepsi bu kadar. Tüm Mercurial etiketleri Git etiketlerine, Mercurial dalları ve yer imleri de Git dallarına dönüştürülmüştür. Şimdi, reponuzu yeni sunucu ana dizinine gönderecek durumdasınız:

Bazaar, Git gibi bir Dağıtık Sürüm Kontrol Sistemi (DVCS) aracıdır ve sonuç olarak bir Bazaar reposunu bir Git reposuna dönüştürmek oldukça basittir. Bunun için bzr-fastimport eklentisini içe aktarmanız gerekecek.

İçe aktarmayı inceleyeceğimiz bir sonraki sistem Perforce’tur. Yukarıda belirttiğimiz gibi Git ve Perforce’un birbirleriyle konuşmasına izin vermenin iki yolu vardır: git-p4 ve Perforce Git Fusion.

Takımınız kaynak kontrolünü TFVC’den Git’e dönüştürüyorsa, bunu en yüksek doğrulukta gerçekleştirmek isteyeceksiniz. Ara işlev bölümünde hem git-tfs’i hem de git-tf’yi ele aldığımızı göz önünde bulundurursak, bu bölümde yalnızca git-tfs’i ele alacağımız anlamına gelir. Çünkü git-tfs dallarını destekler ve bunu git-tf ile yapmak oldukça zordur.

İlk yapmanız gereken şey, kullanıcı adlarını eşlemektir. TFVC değişiklik setleri için yazar alanına neyin gireceği konusunda oldukça serbesttir, ancak Git okunabilir bir ad ve e-posta adresi ister. Bu bilgiyi tf komut satırı istemcisinden şöyle alabilirsiniz:

Bu projenin tarihindeki tüm değişiklik setlerini alır ve bunları işleyeceğimiz AUTHORS_TMP dosyasına koyar. User sütununun (ikinci sütun) verilerini çıkarmak için dosyayı açın ve sütunun hangi karakterlerde başladığını ve bittiğini bulun, ardından aşağıdaki komut satırındaki cut komutunun 11-20 parametrelerini bulunanlarla değiştirin:

cut komutu her satırdan 11 ile 20 arasındaki karakterleri korur. tail komutu başlık alanları ve ASCII alt çizgileri olan ilk iki satırı atlar. Elde edilen sonuç, yinelenenleri ortadan kaldırmak için sort ve uniq e yönlendirilir ve AUTHORS adında bir dosyaya kaydedilir. Sonraki adım el ile yapılmalıdır, git-tfs’nin bu dosyayı etkin bir şekilde kullanabilmesi için her satır bu formatta olmalıdır:

Sol taraftaki bölüm TFVC’den gelen "Kullanıcı" (user) alanıdır, eşittir işaretinin sağ tarafındaki bölüm ise Git işlemleri için kullanılacak olan kullanıcı adıdır.

Bu dosyayı aldıktan sonra, yapmanız gereken sıradaki şey ilgilendiğiniz TFVC projesinin bir kopyasını yapmaktır:

Aşağıdaki komut, katkı mesajlarının altındaki git-tfs-id bölümlerini temizleyecektir:

Bu komut Git-bash ortamındaki sed komutunu kullanarak git-tfs-id: ile başlayan her satırı boş bir metinle değiştirir ve Git’in bu satırları görmezden gelmesini sağlar.

Hepsi tamamlandıktan sonra yeni bir uzak repo ekleyebilir, tüm dalları üstakıma itebilir ve ekibinizin Git üzerinden çalışmaya başlamasını sağlayabilirsiniz.

Eğer sisteminiz yukarıdakilerden biri değilse, çevrimiçi bir içe aktarıcı aramalısınız. Bir çok farklı sistem için CVS, Clear Case, Visual Source Safe ve hatta dizinler için bir arşiv de içeren kaliteli aktarıcılar mevcuttur. Eğer bu araçlardan hiçbiri sizin için uygun değilse, daha az bilinen bir araç kullanıyorsanız veya bir şekilde daha özel bir içe aktarma işlemine ihtiyacınız varsa, git fast-import 'u kullanmalısınız. Bu komut belirli Git verilerini yazmak için stdin’den basit talimatlar okur. Bu şekilde Git nesneleri oluşturmak, ham Git komutlarını çalıştırmaktan veya ham nesneleri yazmaya çalışmaktan çok daha kolaydır (daha fazla bilgi için Dahili Git Ögeleri bölümüne bakın). Bu şekilde, içe aktardığınız sistemden gerekli bilgileri okuyup, stdout’a basit talimatlar yazdıracak bir içe aktarma betiği oluşturabilirsiniz. Ardından, bu programı çalıştırabilir ve çıktısını git fast-import üzerinden akıtarak içe aktarabilirsiniz.

Size hızlı bir şekilde öğretmek için, basit bir içe aktarıcı yazdıracağız. Şimdi, mevcut bir dizinde çalıştığınızı varsayalım. Projenizi zaman zaman dizini zaman damgasıyla işaretlenmiş bir back_YYYY_MM_DD yedek dizinine kopyalayarak yedekliyorsunuz ve bunu Git’e içe aktarmak istiyorsunuz. Dizin yapınız şöyle görünüyor:

Git dizinini içe aktarmak için, Git’in verilerini nasıl depoladığını gözden geçirmeniz gerekir. Hatırlayacağınız üzere, Git temel olarak, içeriğin pozlarına işaret eden katkı nesnelerinin bir listesinden oluşur. Yapmanız gereken tek şey, fast-import ile içerik pozlarının ne olduğunu, onlara işaret eden katkı verilerini ve bunların sıralanma düzenini söylemektir. Stratejiniz pozları tek tek geçerken, her dizinin içeriğini bir önceki katkıyla ilişkilendirekek yeni bir katkı oluşturmaktır.

Bir Örnek: Mecburi Git Politikası bölümünde yaptığımız gibi, genellikle bununla çalıştığımız ve okuması kolay alduğu için kodumuzu Ruby’de yazacağız. Siz aşina olduğunuz herhangi bir dilde de bunu yazabilirsiniz (yalnızca uygun bilgilerin stdout a yazdırılması gerekmektedir). Ve eğer Windows’ta çalışıyorsanız, sadece satır sonuna taşıma dönüşlerini (CRLF) koymamaya, özel bir dikkat göstermeniz gerekecektir. 'git fast-import Windows’un kullandığı satır başı satır beslemelerini (CRLF) değil, yalnızca satır beslemelerini (LF) isteme konusunda çok hassasdır.

Başlamak için, hedef dizine gidip, her birinin bir katkı olarak içe aktarılmasını istediğiniz her alt dizini tanımlayacaksınız. Her alt dizine geçip, onu dışa aktarmak için gerekli komutları yazdırırsınız. Temel ana döngünüz şöyle görünecektir:

Her dizin içinde print_export 'u çalıştırırsınız: bu önceki anlık görüntünün bildirimini ve işaretini alırarak sıradakinin bildirim ve işaretini döndürür. Bu şekilde, onları uygun şekilde bağlayabilirsiniz. Mark katkıya verdiğiniz bir "hızlı-içe-aktarma" tanımıdır: katkı oluşturduğunuzda, her birine başka katkılardan bağlantı kurmak için kullanabileceğiniz bir işaret verirsiniz. Dolayısıyla, print_export yönteminizde yapmanız gereken ilk şey, dizin adından bir işaret oluşturmaktır:

İşaretin bir tamsayı olması gerektiği için, bunu bir dizin serisi oluşturarak ve işaret olarak indeks değerini kullanarak yapacaksınız. Yönteminiz şuna benzer:

Şimdi katkınız bir tam sayı temsilini aldığına göre, katkı meta verileri için bir tarih gerekmektedir. Tarih dizinin adında ifade edildiğinden, bunu dışarı çıkarmanız gerekecektir. print_export dosyanızdaki bir sonraki satır şu şekildedir:

burada convert_dir_to_date şu şekilde tanımlanır:

Bu her dizinin tarihi için bir tamsayı değeri döndürür. Her katkı için ihtiyacınız olan son meta bilgi parçası, global bir değişkene kodladığınız katkı verileridir:

Artık aktarıcınız için katkı verilerini yazdırmaya başlamaya hazırsınız. İlk bilgiler, bir katkı nesnesini tanımladığınızı ve bunun hangi dalda olduğunu; ardından, oluşturduğunuz işareti, katkılayanın bilgilerini ve katkı mesajını; ve onun ardından da -varsa- önceki katkıyı belirtir. Kodunuz şuna benzer:

Yapması kolay olduğu için saat dilimini (-0700) kodlayın. Başka bir sistemden içe aktarıyorsanız saat dilimini fark olarak belirtmeniz gerekir. Katkı mesajı özel bir formatta ifade edilmelidir:

Format: kelime verileri, okunacak verinin boyutu, yeni satır ve son olarak verilerden oluşur. Daha sonra dosya içeriğini belirtmek için aynı biçimi kullanmanız gerektiğinden, export_data adında bir yardımcı yöntem oluşturursunuz:

Geriye kalan tek şey, her poz için dosya içeriğini belirtmektir. Bunların hepsi tek bir dizinde bulunduğu için bu da kolaydır; deleteall komutunu ve ardından dizindeki her dosyanın içeriğini yazdırabilirsiniz. Git daha sonra her pozu uygun şekilde kaydedecektir:

Not: Birçok sistem, revizyonlarını bir katkıdan diğerine yapılan değişiklikler olarak düşündüğünden, hızlı içe aktarma, her bir katkıda hangi dosyaların eklendiğini, kaldırıldığını veya değiştirildiğini; ve yeni içeriklerin neler olduğunu belirtmek için komutlar alabilir. Pozlar arasındaki farkları hesaplayabilir ve yalnızca bu verileri sağlayabilirsiniz, ancak bunu yapmak daha karmaşıktır: Git’e tüm verileri verip, onun çözmesine izin verebilirsiniz. Eğer bu verileriniz için daha uygunsa, verilerinizi bu şekilde nasıl sağlayacağınıza ilişkin ayrıntılar için hızlı içe aktarma kılavuz sayfasına bakın.

Yeni dosya içeriklerini listeleme veya yeni içeriklerle değiştirilmiş bir dosyayı belirtme formatı aşağıdaki gibidir:

Burada mod 644’tür (yürütülebilir dosyalarınız varsa, bunun yerine 755’i tespit edip belirtmeniz gerekir) ve satır içinde bu satırın hemen ardından içerikleri listeleyeceğiniz yazmaktadır. inline_data yönteminiz şuna benzer:

Katkı mesajı verilerinizi belirttiğiniz yöntemle aynı olduğu için daha önce tanımladığınız export_data yöntemini yeniden kullanırsınız.

Yapmanız gereken son şey, bir sonraki yinelemeye aktarılabilmesi için mevcut işareti döndürmektir:

Bu kadar. İşte senaryonun tamamı:

Bu betiği çalıştırırsanız şuna benzer bir içerik elde edersiniz:

Aktarıcıyı çalıştırmak için, içe aktarmak istediğiniz Git dizinindeyken bu çıktıyı git fast-import aracılığıyla aktarın. Yeni bir dizin oluşturabilir ve ardından başlangıç ​​noktası olarak bu dizin içinde git init 'i çalıştırabilir ve ardından betiğinizi çalıştırabilirsiniz:

Gördüğünüz gibi, başarıyla tamamlandığında, size neleri başardığına dair bir sürü istatistik veriyor. Burada, 1 dalda 4 katkı için toplam 13 nesneyi içe aktardınız. Artık yeni geçmişinizi görmek için git log 'u çalıştırabilirsiniz:

İşte güzel ve temiz bir Git reposu. Hiçbir şeyin henüz alınmadığını farketmeniz önemlidir (başlangıçta çalışma dizininizde herhangi bir dosya yoktur). Bunları almak için dalınızı, şu anda master 'ın olduğu yere sıfırlamanız gerekmektedir:

fast-import aracıyla çok daha fazlasını yapabilirsiniz; farklı modları, ikili verileri, birden fazla dallanmayı ve birleştirmeyi, etiketleri, ilerleme göstergelerini ve daha fazlasını yönetebilirsiniz. Git kaynak kodunun contrib/fast-import dizininde daha karmaşık senaryoların bir dizi örneği mevcuttur.