Subversion, kaynak kodlarını yönetmek için çoğu açık kaynak geliştirme projesin ve birçok kurumsal proje tarafından kullanılmaktadır. On yıldan fazla bir süredir mevcuttur ve çoğu zaman açık kaynak projeleri için de facto VCS seçimi olmuştur. Ayrıca, CVS öncesi kaynak kontrol dünyasının büyük oyuncusu olan CVS ile birçok açıdan benzerdir.
Git’in harika özelliklerinden biri, git svn olarak adlandırılan Subversion’a iki yönlü bir köprüdür.
Bu araç, Git’i bir Subversion sunucusuna geçerli bir istemci olarak kullanmanızı sağlar, böylece Git’in tüm yerel özelliklerini kullanabilir ve ardından sanki yerel olarak Subversion kullanıyormuş gibi bir Subversion sunucusuna gönderebilirsiniz.
Bunun anlamı iş arkadaşlarınızın karanlık ve eski yöntemlerle çalışmaya devam ederken, sizin yerel dal oluşturma, birleştirme, izleme alanı kullanma, yeniden temelleme ve cherry-picking gibi işlemleri yapabilmenizdir.
Bu Git’i kurumsal ortamınıza sızdırmanın ve altyapının tamamen Git’i destekleyecek şekilde değiştirilmesi için lobi yaparken, diğer geliştiricilerinizi daha verimli hale getirmenin iyi bir yoludur.
Subversion köprüsü, DVCS dünyasına giriş ilacıdır.
Git’in tüm Subversion köprüleme komutları için temel komutu git svn 'dir.
Birkaç basit iş akışını incelerken en yaygın olanlarını göstereceğiz.
git svn kullanırken, Git’ten çok farklı bir çalışma sistemine sahip olan Subversion ile etkileşimde bulunduğunuzu unutmamalısınız.
Yerel dal oluşturup birleştirebilirsiniz, ancak genellikle çalışmanızı yeniden temelleyerek mümkün olduğunca çizgisel tutmak ve bir Git uzak deposuyla eş zamanlı etkileşimde bulunmaktan kaçınmak en iyisidir.
Geçmişinizi yeniden yazıp, tekrar göndermeye çalışmayın ve bir Git reposuna başka geliştiricilerle eş zamanlı itmeye çalışmayın. Subversion yalnızca tek bir çizgisel geçmişe sahip olabilir ve onun kafasını karıştırmak çok kolaydır. Bir ekip ile çalışıyorsanız ve bazıları SVN kullanırken diğerleri Git kullanıyorsa, herkesin işbirliği yapmak için SVN sunucusunu kullandığından emin olun (bu hayatınızı kolaylaştıracaktır).
Bu işlevselliği göstermek için yazma erişiminiz olan tipik bir SVN reposuna ihtiyacınız var.
Bu örnekleri kopyalamak istiyorsanız, yazılabilir bir SVN test reposunun bir kopyasını oluşturmanız gerekecektir.
Bunu kolayca yapmak için, Subversion ile birlikte gelen svnsync adlı bir aracı kullanabilirsiniz.
Takip edebilmek için önce yeni bir yerel Subversion reposu oluşturmanız gerekiyor:
$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svnSonra, tüm kullanıcıların revprops’ları değiştirmesine izin verin: kolay yol, her zaman 0 (sıfır) çıkışlı bir pre-revprop-change betiği eklemektir:
$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-changeŞimdi svnsync init komutunu "to" ve "from" repolarıyla kullanarak bu projeyi yerel makinenize senkronize edebilirsiniz.
$ svnsync init file:///tmp/test-svn \
http://your-svn-server.example.org/svn/Bu komut senkronizasyonu çalıştırmak için özellikleri ayarlar. Kodu kopyalamak için şunu çalıştırabilirsiniz:
$ svnsync sync file:///tmp/test-svn
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .............................[...]
Committed revision 2.
Copied properties for revision 2.
[…]Bu işlem normalde sadece birkaç dakika sürmesine rağmen, eğer orijinal repoyu başka bir uzak repoya kopyalamaya çalışırsanız, neredeyse bir saat sürecektir (100’den az katkı olsa bile). Subversion her bir revizyonu tek tek kopyalamak ve ardından başka bir repoya geri itmek zorundadır. Gülünç derecede verimsiz olmasına rağmen, bunu yapmanın tek kolay yolu budur.
Şimdi yazma erişimimiz olan bir Subversion reposuna sahip olduğumuza göre, tipik bir iş akışının üzerinden geçebiliriz.
Bir Subversion reposunu yerel bir Git reposuna aktaran git svn clone komutuyla başlayacağız.
Eğer canlıda olan gerçek bir Subversion reposundan içe aktarıyorsanız, buradaki file:///tmp/test-svn 'yi Subversion reposunuzun URL’siyle değiştirmeyi unutmayın:
$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
Initialized empty Git repository in /private/tmp/progit/test-svn/.git/
r1 = dcbfb5891860124cc2e8cc616cded42624897125 (refs/remotes/origin/trunk)
A m4/acx_pthread.m4
A m4/stl_hash.m4
A java/src/test/java/com/google/protobuf/UnknownFieldSetTest.java
A java/src/test/java/com/google/protobuf/WireFormatTest.java
…
r75 = 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae (refs/remotes/origin/trunk)
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/my-calc-branch, 75
Found branch parent: (refs/remotes/origin/my-calc-branch) 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae
Following parent with do_switch
Successfully followed parent
r76 = 0fb585761df569eaecd8146c71e58d70147460a2 (refs/remotes/origin/my-calc-branch)
Checked out HEAD:
file:///tmp/test-svn/trunk r75Bu girdiğiniz URL üzerinde git svn init ve ardından git svn fetch komutlarının eşdeğerini çalıştırır.
İşlemin gerçekleşmesi biraz zaman alabilir.
Örneğin, test projesinde yaklaşık 75 katkı varsa ve kod tabanı çok büyük değilse, Git yine de her sürümü tek tek kontrol etmeli ve bunu bireysel olarak katkılamaladır.
Yüzlerce veya binlerce katkı içeren bir proje için, bunun tamamlanması gerçekten saatler, hatta günler alabilir.
-T trunk -b branches -t tags kısmı, bu Subversion reposunun temelleme ve etiketleme kurallarını takip ettiğini Git’e belirtir.
Eğer ana dalınızı (trunk), dallarınızı veya etiketlerinizi farklı adlandırırsanız, bu seçenekleri değiştirebilirsiniz.
Bu çok yaygın olduğu için, ilgili kısmı -s ile değiştirebilirsiniz: bu standart düzeni ima eder ve tüm bu seçenekleri içerir.
Aşağıdaki komuta eşdeğerdir:
$ git svn clone file:///tmp/test-svn -sBu noktada, dallarınızı ve etiketlerinizi içe aktarmış geçerli bir Git reponuz olmalıdır:
$ git branch -a
* master
remotes/origin/my-calc-branch
remotes/origin/tags/2.0.2
remotes/origin/tags/release-2.0.1
remotes/origin/tags/release-2.0.2
remotes/origin/tags/release-2.0.2rc1
remotes/origin/trunkBu aracın Subversion etiketlerini uzak referanslar olarak nasıl yönettiğine dikkat edin.
Git tesisat (plumbing) komutu show-ref ile daha yakından inceleyelim:
$ git show-ref
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/heads/master
0fb585761df569eaecd8146c71e58d70147460a2 refs/remotes/origin/my-calc-branch
bfd2d79303166789fc73af4046651a4b35c12f0b refs/remotes/origin/tags/2.0.2
285c2b2e36e467dd4d91c8e3c0c0e1750b3fe8ca refs/remotes/origin/tags/release-2.0.1
cbda99cb45d9abcb9793db1d4f70ae562a969f1e refs/remotes/origin/tags/release-2.0.2
a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2rc1
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunkGit, bir Git sunucusundan kopyaladığında bunu yapmaz; işte taze bir kopya sonrası etiketlere sahip bir reponun görüntüsü:
$ git show-ref
c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
32ef1d1c7cc8c603ab78416262cc421b80a8c2df refs/remotes/origin/branch-1
75f703a3580a9b81ead89fe1138e6da858c5ba18 refs/remotes/origin/branch-2
23f8588dde934e8f33c263c6d8359b2ae095f863 refs/tags/v0.1.0
7064938bd5e7ef47bfd79a685a62c1e2649e2ce7 refs/tags/v0.2.0
6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0Git etiketleri uzak dallar gibi işlemek yerine doğrudan refs/tags içine çeker.
Artık bir çalışma dizininiz olduğuna göre, Git’i bir SVN istemcisi olarak etkili bir şekilde kullanarak proje üzerinde biraz çalışabilir ve katkılarınızı üst-akıma itebilirsiniz. Dosyalardan birini düzenleyip katkılarsanız, Git’te yerel olarak işlenmiş ancak henüz Subversion sunucusunda bulunmayan bir katkıya sahip olursunuz:
$ git commit -am 'Adding git-svn instructions to the README'
[master 4af61fd] Adding git-svn instructions to the README
1 file changed, 5 insertions(+)Sonraki adım, değişikliklerinizi yukarı akıma itmektir.
Subversion ile çalışma şeklinizin değiştiğine dikkat edin: çevrimdışı olarak birkaç katkı yapabilir ve ardından hepsini aynı anda Subversion sunucusuna itebilirsiniz.
Bir Subversion sunucusuna itmek için git svn dcommit komutunu çalıştırırsınız:
$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
M README.txt
Committed r77
M README.txt
r77 = 95e0222ba6399739834380eb10afcd73e0670bc5 (refs/remotes/origin/trunk)
No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunkBu, Subversion sunucusu kodunun üstüne yaptığınız tüm katkıları alır, her biri için bir Subversion katkısı yapar ve ardından yerel Git katkınızı benzersiz bir kimlik içerecek şekilde yeniden yazar. Bu tüm katkılarınızın SHA-1 kontrol toplamlarının değiştiği anlamına gelmesi yönünden önemlidir. Kısmen bu nedenle, eşzamanlı olarak projelerinizin Git tabanlı uzak sürümleriyle ve bir Subversion sunucusuyla çalışmak iyi bir fikir değildir. Son katkıya baktığınızda, eklenen yeni `git-svn-id`yi görebilirsiniz:
$ git log -1
commit 95e0222ba6399739834380eb10afcd73e0670bc5
Author: ben <ben@0b684db3-b064-4277-89d1-21af03df0a68>
Date: Thu Jul 24 03:08:36 2014 +0000
Adding git-svn instructions to the README
git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68İlk olarak katkıladığınız 4af61fd ile başlayan SHA-1 kontrol toplamının şimdi 95e0222 ile başladığını görüyorsunuz.
Eğer hem bir Git sunucusuna hem de bir Subversion sunucusuna itmek istiyorsanız, katkı verilerinizin değişmesi nedeniyle önce Subversion sunucusuna (dcommit) itmelisiniz.
Diğer geliştiricilerle çalışıyorsanız, o zaman biriniz bir noktada kodunu itecek ve ardından diğeri öbürüyle çakışan bir değişiklik itmeye çalışacaktır.
Bu değişiklik, siz onların çalışmasını kendinizinkiyle birleştirmedikçe reddedilecektir.
git svn 'de durum şöyle görünür:
$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: d5837c4b461b7c0e018b49d12398769d2bfc240a and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 f414c433af0fd6734428cf9d2a9fd8ba00ada145 c80b6127dd04f5fcda218730ddf3a2da4eb39138 M README.txt
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.Bu durumu çözmek için git svn rebase komutunu çalıştırabilirsiniz.
Bu komut, sunucudaki henüz sahip olmadığınız tüm değişiklikleri indirir ve yaptığınız çalışmayı sunucudaki mevcut durumun üstüne yerleştirir:
$ git svn rebase
Committing to file:///tmp/test-svn/trunk ...
ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: eaa029d99f87c5c822c5c29039d19111ff32ef46 and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 65536c6e30d263495c17d781962cfff12422693a b34372b25ccf4945fe5658fa381b075045e7702a M README.txt
First, rewinding head to replay your work on top of it...
Applying: update foo
Using index info to reconstruct a base tree...
M README.txt
Falling back to patching base and 3-way merge...
Auto-merging README.txt
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.Şimdi, tüm çalışmanız Subversion sunucusundaki durumun üstüne yerleşmiş olduğu için, başarıyla dcommit yapabilirsiniz:
$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
M README.txt
Committed r85
M README.txt
r85 = 9c29704cc0bbbed7bd58160cfb66cb9191835cd8 (refs/remotes/origin/trunk)
No changes between 5762f56732a958d6cfda681b661d2a239cc53ef5 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunkKodunuzu itmeden önce henüz sahip olmadığınız değişikleri yukarı akımdan çekmenizi gerektiren Git’in aksine, git svn bunu ancak değişiklikler çakıştığında yapmanızı gerektirir (Subversion’ın çalışma şekli gibi).
Birisi bir dosyaya bir değişiklik yaptıktan sonra siz de başka bir dosyada bir değişiklik yaparsanız, dcommit sorunsuz çalışacaktır:
$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
M configure.ac
Committed r87
M autogen.sh
r86 = d8450bab8a77228a644b7dc0e95977ffc61adff7 (refs/remotes/origin/trunk)
M configure.ac
r87 = f3653ea40cb4e26b6281cec102e35dcba1fe17c4 (refs/remotes/origin/trunk)
W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ, using rebase:
:100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 e757b59a9439312d80d5d43bb65d4a7d0389ed6d M autogen.sh
First, rewinding head to replay your work on top of it...Kodunuzu ittiğinizde herhangi birinizin bilgisayarında var olmayan bir proje durumu elde edeceğiniz için bu önemlidir. Değişiklikler ister uyumsuz olsun ister çakışmasın, teşhis etmesi zor sorunlarla karşılaşabilirsiniz. Bu bir Git sunucusu kullanmaktan farklıdır: Git’te, yayınlamadan önce istemcinizdeki durumu tamamen test edebilirsiniz, SVN’de ise katkı öncesi ve sonrası durumların aynı olduğundan kesinlikle emin olamazsınız.
Kendiniz katkı işlemeye hazır olmasanız bile, bu komutu Subversion sunucusundan değişiklikleri çekmek için çalıştırmalısınız.
Yeni verileri almak için git svn fetch komutunu çalıştırabilirsiniz ancak git svn rebase hem çekme yapar hem de yerel katkılarınızı günceller.
$ git svn rebase
M autogen.sh
r88 = c9c5f83c64bd755368784b444bc7a0216cc1e17b (refs/remotes/origin/trunk)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/trunk.Arada bir git svn rebase 'i çalıştırmak kodunuzun her zaman güncel olmasını sağlar.
Ancak bunu çalıştırdığınızda çalışma dizininizin temiz olduğundan emin olmalısınız.
Yerel değişiklikleriniz varsa, git svn rebase 'i çalıştırmadan önce çalışmanızı saklamanız veya geçici olarak kaydetmeniz gerekir; aksi takdirde, rebase’in birleştirme çakışmasına yol açacağını görürse komut duracaktır.
Git iş akışına alıştığınızda, muhtemelen konu dalları oluşturacak, bunlar üzerinde çalışacak ve sonra bunları birleştireceksiniz.
Eğer bir Subversion sunucusuna git svn yoluyla itiyorsanız, dalları birleştirmek yerine çalışmanızı her seferinde tek bir dal üzerinde yeniden temellemek isteyebilirsiniz.
Yeniden temellemeyi tercih etmenin nedeni, Subversion’un doğrusal bir geçmişe sahip olması ve Git gibi birleştirmelerle ilgilenmemesidir.
Dolayısıyla git svn, anlık pozları Subversion katkılarına dönüştürürken yalnızca ilk önceli takip eder.
Geçmişinizin şuna benzediğini varsayalım: bir experiment dalı oluşturdunuz, iki katkı işlediniz ve ardından bunları tekrar master olarak birleştirdiniz.
Dcommit yaptığınızda şöyle bir çıktı görürsünüz:
$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
M CHANGES.txt
Committed r89
M CHANGES.txt
r89 = 89d492c884ea7c834353563d5d913c6adf933981 (refs/remotes/origin/trunk)
M COPYING.txt
M INSTALL.txt
Committed r90
M INSTALL.txt
M COPYING.txt
r90 = cb522197870e61467473391799148f6721bcf9a0 (refs/remotes/origin/trunk)
No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunkGit proje geçmişinize bakmadığınız sürece birleştirilmiş geçmişe sahip bir dalda dcommit çalıştırmak sorunsuz çalışır.
Ancak experiment dalında yaptığınız katkıların hiçbirinin yeniden yazmılamış, bunun yerine tüm bu değişikliklerin SVN sürücüsünde tek bir birleştirme katkısının altında toplanmış olduğunu görürsünüz.
Başka biri bu çalışmayı kopyaladığında, sanki git merge --squash çalıştırmışsınız gibi, tüm çalışmaların içine sıkıştırıldığı birleştirme katkısını görürler.
Bunların nereden geldiğine veya ne zaman işlendiğine ilişkin katkı verilerini göremezler.
Subversion’daki dallanma Git’tekiyle aynı değildir: en iyisi, onu çok fazla kullanmaktan kaçınmaktır.
Ancak Subversion’da git svn kullanarak dallar oluşturabilir ve bunlara katkı işleyebilirsiniz.
Subversion’da yeni bir dal oluşturmak için git svn Branch [new-branch] komutunu çalıştırın:
$ git svn branch opera
Copying file:///tmp/test-svn/trunk at r90 to file:///tmp/test-svn/branches/opera...
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/opera, 90
Found branch parent: (refs/remotes/origin/opera) cb522197870e61467473391799148f6721bcf9a0
Following parent with do_switch
Successfully followed parent
r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera)Bu, Subversion’daki svn copy trunk Branch/Opera komutunun eşdeğerini yapar ve Subversion sunucusunda çalışır.
Sizi o dala geçirmediğini akılda tutmak önemlidir; eğer bu noktada katkıda bulunursanız, bu katkı sunucudaki opera 'ya değil trunk 'a gidecektir.
Git geçmişinizdeki herhangi bir Subversion dalınızın ipucunu arayarak dcommit’lerinizin hangi şubeye gittiğini belirler.
Yalnızca bir taneye sahip olmalısınız ve bu, mevcut dal geçmişinizde `git-svn-id 'ye sahip son dal olmalıdır.
Aynı anda birden fazla dal üzerinde çalışmak istiyorsanız, yerel dalları belirli Subversion şubelerine dcommit edecek şekilde ayarlayabilirsiniz.
Bunları o dal için içe aktarılan Subversion işleminde başlatabilirsiniz.
Ayrı ayrı çalışabileceğiniz bir opera dalı istiyorsanız aşağıdaki komutu çalıştırabilirsiniz.
$ git branch opera remotes/origin/operaŞimdi, eğer opera dalınızı trunk (master dalınız) ile birleştirmek istiyorsanız, bunu normal bir git merge ile yapabilirsiniz.
Ancak (-m aracılığıyla) açıklayıcı bir katkı mesajı girmeniz gerekir, aksi takdirde birleştirme, yararlı bir şey yerine "opera dalını birleştir" diyecektir.
Bu işlemi gerçekleştirmek için git merge kullanıyor olsanız ve (Git sizin için uygun birleştirme tabanını otomatik olarak algılayacağı için) birleştirme muhtemelen Subversion’dakinden çok daha kolay olsa da, bunun normal bir birleştirme işlemi olmadığını unutmayın.
Bu verileri, birden fazla önceli olan bir katkıyı işleyemeyen bir Subversion sunucusuna geri göndermeniz gerekir.
Yani onu üst akıma ittikten sonra, başka bir dalın tüm çalışmalarını tek bir katkı altında sıkıştıran bir katkı gibi görünecektir.
Bir dalı diğeriyle birleştirdikten sonra, Git’te normalde yaptığınız gibi kolayca geri dönüp o dal üzerinde çalışmaya devam edemezsiniz.
Çalıştırdığınız dcommit komutu, hangi dalın birleştirildiğini belirten tüm bilgileri siler, dolayısıyla daha sonraki birleştirme temeli hesaplamaları yanlış olur (dcommit komutu sizin git merge sonucunuzu sanki git merge --squash komutunu çalıştırmışsınız gibi görünmesini sağlar).
Ne yazık ki, bu durumu önlemenin iyi bir yolu yoktur (Subversion bu bilgiyi saklayamadığı için, onu sunucunuz olarak kullanırken her zaman sınırlamalarından dolayı bazı şeyler eksik kalacaktır).
Sorunları önlemek için, yerel dalı (burada opera) ana dalla birleştirdikten sonra silmelisiniz.
git svn araç seti Subversion’da sahip olduğunuza benzer bazı işlevler sağlayarak, Git’e geçişi kolaylaştırmaya yardımcı olacak bir dizi komut sunar.
Subversion’un eskiden ne yaptığını size veren birkaç komut:
Subversion’a alışkınsanız ve geçmişinizi SVN çıktı tarzında görmek istiyorsanız, katkı geçmişinizi SVN formatında görüntülemek için git svn log komutunu çalıştırabilirsiniz:
$ git svn log
------------------------------------------------------------------------
r87 | schacon | 2014-05-02 16:07:37 -0700 (Sat, 02 May 2014) | 2 lines
autogen change
------------------------------------------------------------------------
r86 | schacon | 2014-05-02 16:00:21 -0700 (Sat, 02 May 2014) | 2 lines
Merge branch 'experiment'
------------------------------------------------------------------------
r85 | schacon | 2014-05-02 16:00:09 -0700 (Sat, 02 May 2014) | 2 lines
updated the changeloggit svn log hakkında iki önemli şeyi bilmelisiniz:
İlk olarak, Subversion sunucusundan veri isteyen gerçek svn log komutunun aksine çevrimdışı çalışır.
İkincisi, yalnızca Subversion sunucusuna işlenen edilen katkıları gösterir.
dcommit yapmadığınız yerel katkılar görünmediği gibi, bu arada başkalarının Subversion sunucusuna gönderdiği katkılar da görünmez.
Daha ziyade Subversion sunucusundaki katkıların bilinen son durumuna benzer.
git svn log komutu svn log komutunu çevrimdışı olarak simüle ettiği gibi, git svn blame [DOSYA] komutunu çalıştırarak svn annotate in eşdeğerini elde edebilirsiniz.
Çıktıtı aşağıdaki gibi görünür:
$ git svn blame README.txt
2 temporal Protocol Buffers - Google's data interchange format
2 temporal Copyright 2008 Google Inc.
2 temporal http://code.google.com/apis/protocolbuffers/
2 temporal
22 temporal C++ Installation - Unix
22 temporal =======================
2 temporal
79 schacon Committing in git-svn.
78 schacon
2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol
2 temporal Buffer compiler (protoc) execute the following:
2 temporalYine Git’te yerel olarak yaptığınız veya geçen zamanda Subversion’a aktarılan katkıları göstermez.
Ayrıca svn info 'nun size sağladığı bilgilerin aynısını git svn info 'yu çalıştırarak da alabilirsiniz:
$ git svn info
Path: .
URL: https://schacon-test.googlecode.com/svn/trunk
Repository Root: https://schacon-test.googlecode.com/svn
Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029
Revision: 87
Node Kind: directory
Schedule: normal
Last Changed Author: schacon
Last Changed Rev: 87
Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)Bu kod blame ve log gibi çevrimdışı çalışır ve en son Subversion sunucusuyla iletişim kurduğunuz zaman kadar günceldir.
Eğer herhangi bir yerde svn:ignore özellikleri ayarlanmış bir Subversion reposunu kopyalarsanız, muhtemelen göndermemeniz gereken dosyaları yanlışlıkla göndermemek için .gitignore dosyalarını ayarlamak istersiniz.
Bu sorunu çözmeye yardımcı olan iki git svn komutu vardır:
Bunlardan ilki, bir sonraki işleminizin bunları içerebilmesi için otomatik olarak ilgili .gitignore dosyalarını sizin için oluşturan git svn create-ignore` komutudur.
İkinci komut ise git svn show-ignore olup, çıktıyı proje hariç tutma (ignore) dosyanıza yeniden yönlendirebilmeniz için bir .gitignore dosyasına koymanız gereken satırları stdout olarak yazdırır:
$ git svn show-ignore > .git/info/excludeBu şekilde, projeyi .gitignore dosyalarıyla kirletmemiş olursunuz.
Bu Subversion ekibinde tek Git kullanıcısı olduğunuz ve ekip arkadaşlarınızın projede .gitignore dosyalarını istemediği durumlar için iyi bir seçenektir.
git svn araçları bir Subversion sunucusunda sıkışıp kaldıysanız veya başka bir geliştirme ortamında bir Subversion sunucusunu çalıştırmanız gerekiyorsa faydalıdır.
Ancak bu araçları kısıtlı Git olarak düşünmelisiniz, aksi takdirde sizin ve ekip arkadaşlarınızın kafasını karıştıracak çeviri sorunlarıyla karşılaşabilirsiniz.
Sorun yaşamamak için şu kuralları izlemeye çalışın:
-
git mergeile yapılan birleştirme işlemleri içermeyen çizgisel bir Git geçmişi tutun. Ana dalınız dışındaki herhangi bir işi birleştirmek yerine anadala geri dönerek yeniden temmelleyin. -
Ayrı bir Git sunucusu kurmayın ve üzerinde işbirliği yapmayın. Yeni geliştiriciler için kopyalamaları hızlandırmak için bir taneniz olabilir, ancak
git-svn-idgirişi olmayan hiçbir şeyi itmek için kullanmayın. Her bir katkı mesajınıgit-svn-idiçin kontrol ederek, mesajı olmayan katkıları reddecek birpre-receivekancası dahi ekleyebilirsiniz.
Bu kuralları izlerseniz, bir Subversion sunucusu ile çalışmak daha katlanılabilir bir hale gelir. Ancak, mümkünse gerçek bir Git sunucusuna geçmek, takımınıza çok daha fazla fayda sağlayabilir.