Subversion S.S.S. (Sık Sorulan Sorular)

Bu belge Subversion'ın 1.0.9 sürümünde bulunan subversion-1.0.9/www/project_faq.html dosyasının bir çevirisidir. (Çeviri esnasında bazı noktalarda konuyu daha anlaşılır kılmak için (cümle bazında) bir kaç ekleme ve çıkarma olduğundan, çeviri birebir bir nitelik taşımamaktadır.) Subversion için geçerli yazılım lısansı bu belgeyi de lisans şartları gereği kapsamaktadır.

Çevirinin güncel bir versiyonuna http://www.students.itu.edu.tr/~yazicivo/doc/subversion-sss.html adresinden ulaşabilirsiniz.


İçindekiler

Genel Sorular

  1. Neden böyle bir proje mevcut?
  2. Subversion müseccel bir yazılım mı? Subversion'ın CollabNet'e ait olduğunu duydum.
  3. Kendi projelerimde kullanmak için Subversion yeterli kararlılığa sahip mi?
  4. Subversion'ın istemci/sunucu uyumluluğunda izlediği yöntem nedir?
  5. Subversion hangi işletim sistemleri üzerinde çalışabilir?
  6. Bu yeni dosya sistemi nasıl bir şey? Ext2 benzeri bir şey mi yoksa?
  7. Subversion'ın bir Apache eklentisi olduğunu duydum. Subversion sunucular için ne kullanıyor?
  8. Yani bu Subversion kullanmak için Apache yüklemek zorunda olduğum anlamına mı geliyor?
  9. Şu an Apache 1.x kullanıyorum ve Subversion arşivlerini sunmak için Apache 2.0 kuramam. Bu bir Subversion sunucusu çalıştıramayacağım anlamına mı geliyor?
  10. Neden SCM'nin (Kaynak Kontrol Yönetimi [Source Control Management]) Y sistemi gibi bir X sistemi kullanmıyorsunuz?
  11. Neden tüm arşivim aynı revizyon numarasını paylaşıyor? Tüm projelerimin kendinlerine ait revizyon numaralarının olmasını istiyorum.
  12. Subversion `changeset' özelliğine sahip mi?
  13. Subversion'ın yeni sürümü ne zaman çıkacak?
  14. Subversion `symlink' (sembolik bağlantı) destekliyor mu?
  15. Subversion'ın yüksek çözünürlükte bir logosuna ihtiyacım var. Bunu nereden bulabilirim?
  16. Sormak istediğim başka sorularım var. Daha fazla bilgiye nereden ulaşabilirim?

Nasıl ... yapabilirim?

  1. Subversion'ın kaynak kodunu nasıl kendi çalışma dizinime çekebilirim (`checkout' edebilirim)?
  2. Nasıl bir arşiv oluşturup içine veri atabilirim?
  3. Önceki bir CVS arşivimi, nasıl bir Subversion arşivine çevirebilirim?
  4. Ya eğer bir proxy arkasındaysam?
  5. Sistem yöneticilerim Subversion için bir HTTP sunucu kurmama izin vermiyor? Uzaktan erişim istiyorsam başka bir yolum var mı?
  6. Subversion altında birden fazla projeyi nasıl yönetebilirim?
  7. Birbirinden tamamen farklı iki arşivi nasıl birleştirebilirim?
  8. Arşivimi ya da elimdeki çalışma kopyamın yedeğini bir NFS sunucu üstünde tutmalı mıyım?
  9. Neden arşivim çok yer kaplıyor?
  10. Arşiv izinlerini nasıl doğru bir şekilde ayarlayabilirim?
  11. Neden `read-only' işlemler için de arşive yazma izni gerekiyor?
  12. Bir dosyayı arşivden nasıl tamamen silebilirim?
  13. Onaylanan bir değişikliğin log mesajını daha sonradan nasıl değiştirebilirim?
  14. Subversion için yazdığım bir yamayı nasıl onaylatabilirim?
  15. Arşivde belirli bir yere nasıl dosya aktarma (`import') işlemi gerçekleştirebilirim? (Orjinal arşiv kopyasında herhangi bir yerdeğiştirme ya da silme işlemi yapmadan, sıfırdan bir arşiv kolu oluşturmak gibi.)
  16. Bazılarının Subversion sunucularını yükseltirken bahsettikleri "dök/yükle (`dump/load') döngüsü" tam olarak ne anlama geliyor?
  17. İstemcilerin bir SSPI kimlik denetimi kullanarak Windows `domain controller'dan sisteme giriş yapmalarını nasıl sağlayabilirim?
  18. ".svn" dizin isimleri hoşuma gitmedi; "SVN" tarzı bir şeyi daha çok tercih ederdim. Bunu nasıl değiştirebilirim?
  19. Bir dosyanın büyük-küçük harfini nasıl değiştirebilirim?
  20. Birleştirme (`merge') işlemi için CVS'de kullandığım `tag'ları kullanabilir miyim?
  21. Neden $Revision$ anahtar değişkeni değer olarak dosyanın değiştirilmiş son revizyon numarasını alıyor; halbuki ben o anki geçerli sürüm numarasını almasını istiyorum.
  22. Subversion da CVS'deki $Log$ gibi bir anahtar değişkene sahip mi?
  23. Projemdeki bir dosyanın yerel kullanıcılar tarafından paylaşılabilmesini, ama yapılan değişikliklerin arşive asla geçirilememesini istiyorum. Bu dosya için `svn commit'i nasıl etkisiz hale getirebilirim?
  24. Herhangi bir arşive svn+ssh ile giriş yaptığımda şifrem ~/.subversion/auth/ içinde saklanmıyor. Her seferinde şifreyi baştan yazmaktan başka bir yol var mı?
  25. Arşivdeki tüm dosyalar üzerindeki bazı özellikleri nasıl ayarlayabilirim? Ve arşive yeni eklenen tüm dosyaların da bu özelliğe sahip olduğuna nasıl emin olurum?
  26. Arşivimin hangi Berkeley DB sürümünü kullandığını nasıl anlayabilirim?
  27. Arşivimde bir internet sayfasının kayıtlarını tutuyorum. Yaptığım her değişiklik onayından sonra asıl internet sayfasının da aynı anda bu güncellemeleri yapmasını nasıl sağlayabilirim?
  28. Nasıl arşivdeki tek bir dosyayı çalışma dizinime çekebilirim?
  29. Çalışma dizinimdeki bütün ekleme, silme, kopyalama ve isim değiştirme işlemlerinden, tüm bu işlemler olduktan sonra nasıl haberdar olabilirim?

Sorun Giderme

  1. Arşivim sürekli kurtarma işlemine (DB_RUNRECOVERY) ihtiyacı olduğu yönünde hatalar verip donuyor. Bunun sebebi ne olabilir?
  2. Ne zaman arşive erişmeye çalışsam işlemim hep donup kalıyor. Arşivim zarar mı görmüş?
  3. Ne zaman bir svn komutu çalıştırsam, çalışma dizininin kilitlendiği şeklinde uyarı veriyor. Arşivim zarar görmüş olabilir mi?
  4. Yaptığım değişiklikleri onaylatmaya çalıştığımda Subversion kopyamın tarihinin geçmiş olduğu uyarısını veriyor.
  5. Dağıtımım ile gelen derlenmiş Subversion paketlerini kurdum ve Subversion'ı çalışma dizinime çekmeye çalıştığımda "Unrecognized URL scheme." hatası alıyorum. Bu neden kaynaklı olabilir?
  6. Arşivimi aramaya ya da açmaya çalıştığımda hata alıyorum, fakat arşivin URL'sini doğru girdiğimden eminim. Nerede yanlış yapıyor olabilirim?
  7. configure, komutunu çalıştırdığımda subs-1.sed line 38: Unterminated `s' command. hatası alıyorum. Sorun neden kaynaklı olabilir?
  8. Subversion'ı *NIX altında BerkeleyDB 4.2 desteği ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım?
  9. Subversion'ı Windows altında MSVC++ 6.0 ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım?
  10. file: URL'sinde bir Windows sürücüsünün harfini nasıl yazabilirim?
  11. VS.NET/ASP.NET'in ".svn" dizini ile ufak bir uyuşmazlığı var gibi. Bu durumda ne yapabilirim?
  12. Ağ üzerinden bir Subversion arşivine yaptığım değişiklikleri onaylatmaya çalışırken sorun yaşıyorum.
  13. Windows XP üzerinde çalışan Subversion sunucum bazen zarar görmüş veri yolluyor gibi. Böyle bir şey gerçekten olabilir mi?
  14. Subversion sunucusu ile istemci arasında geçen haberleşmeyi en iyi şekilde ağdan nasıl dinleyebilirim?
  15. Neden svn revert açık bir hedefe ihtiyaç duyuyor? Neden öntanımlı olarak rekürsif değil? Bu özelliği neredeyse diğer tüm komutlar ile farklılaşıyor.
  16. Apache'yi başlattığımda mod_dav_svn db-4.X sürümü yerine db-3.X sürümünü bulduğundan "bad database version" hatası veriyor.
  17. RedHat 9'da "Function not implemented" hataları aldığımdan Subversion hiçbir şekilde çalışmıyor. Bu sorunu nasıl giderebilirim?
  18. Neden SVN log dosyasına Apache ile onaylatılan değişikliklerde, değişikliği yapan kullanıcı olarak "(no author)" ibaresi düşülüyor.
  19. Arada sırada "Access Denied" hataları alıyorum Windows'ta. Genelde rastgele zaman aralıklarında tekrarlıyor bu hatayı. Neden kaynaklı olabilir?
  20. FreeBSD üzerindeyken bazı komutlar (özellikle svnadmin create) zaman zaman donuyor. Neden kaynaklı olabilir?
  21. Arşivimi bir internet tarayıcısı ile sorunsuz görüntüleyebildiğim halde, svn checkout ile arşive erişmeye çalıştığımda "301 Moved Permanently" şeklinde bir hata alıyorum. Sorun neden kaynaklı olabilir?
  22. Bir dosyanın eski bir sürümüne svn ile bakmaya çalıştığımda "path not found" hatası alıyorum. Bunun sebebi ne olabilir?
  23. HTTP Digest auth neden çalışmıyor olabilir?
  24. AIX üzerinde xlc ile derlemeye çalıştığımda hata alıyorum. Neden kaynaklı olabilir?
  25. Arşivden bir dizini (-N parametresi ile) rekürsif olmayacak şekilde çalışma dizinime çektikten sonra, bazı alt dizinlerin görünmesini istiyorum. Fakat svn up subdir ile bunu yapamıyorum.
  26. mod_dav_svn'yi Windows üzerinde Apache ile çalıştırmaya çalıştığımda, mod_dav_svn.so dosyasını doğru yer olan \Apache\modules altına koyduğum halde, Apache'den modülü bulamadığına dair hata alıyorum.
  27. Neden arşiv askılarım çalışmıyor. Dışarıdan program çağırmaları gerektiği halde hiç de öyle bir çağrı yolluyor gözükmüyorlar.
  28. Neden --diff-cmd parametresi ile -u parametresini kullandığımda uyarı alıyorum. --extensions parametrei ile bunu etkisiz kılmaya çalıştığım halde olmuyor.
  29. Ana! Subversion istemcim şifrelerimi düz bir metin dosyasında tuttuyor. Yuh!
  30. "svn: bdb: call implies an access method which is inconsistent with previous calls" hatası alıyorum. Bunu nasıl düzeltebilirim?
  31. `hotbackup' ile arşivimin yedeğini almaya çalıştığımda, svnadmin 2Gb'den büyük dosyalarda hata veriyor.
  32. Henüz yeni onayladığım bir dosya için ilgili log kayıtlarını göremiyorum. Neden olabilir?

Geliştirici Soruları

  1. Bellek diski (`ram disk') üzerinde nasıl regresyon testi yapabilirim?

Referanslar

  1. Subversion tarafından kullanılan tüm HTTP metodları neler?
  2. 'bikeshed' de nedir?
  3. 'baton' tam olarak nedir?
  4. Arşiv kesilmiş (`wedged') denerek aslında ne kastediliyor?

Genel Sorular

  1. Neden böyle bir proje mevcut? [Y, A]

    CVS kullanıcısını ele geçirmek için. Yapmaya çalıştığımız daha çok CVS'in eskik birçok yanını tamamlayarak yeni bir versiyon kontrol sistemi oluşturmak. Daha fazla bilgi için anasayfamıza bakabilirsiniz.

  2. Subversion müseccel bir yazılım mı? Subversion'ın CollabNet'e ait olduğunu duydum. [Y, A]

    Hayır, Subversion açık kaynak kodlu, özgür bir yazılım. CollabNet sadece tüm zamanını yazılım geliştirmeye harcayan geliştiricilerin ücretlerini ödeyerek, yazılım kodunun telif haklarını, Debian Özgür Yazılım Kılavuzu ile uyumlu Apache/BSD-stili bir lisans ile, elinde tutuyor. Diğer bir ifadeyle, Subversion'ı CollabNet ya da başka birinden hiçbir şekilde izin almaya gerek kalmadan, istediğiniz şekilde bilgisayarınıza yükleyebilir, Subversion'ın üzerinde değişiklikler yapabilir ve onu dağıtabilirsiniz.

  3. Kendi projelerimde kullanmak için Subversion yeterli kararlılığa sahip mi? [Y, A]

    Evet, kesinlikle. Başlıca öneme sahip olan (`prime-time') üretimler için kullanıma hazırdır.

    Subversion 2000 yılından beri geliştirilmektedir ve gelişiminden 1 yıl sonra kendi kendini sunabilecek hale gelmiştir. Bir yıl sonra "alpha" sürümü duyurulduğu zaman ise zaten düzinelerce geliştirici ve şirket tarafından zaten kullanılmaktaydı. "alpha" sürümünün duyurulmasından sonraki iki sene boyunca, yazılım 1.0 sürümüne ulaşana kadar, hataları düzeltilip daha yazılımın kararlı bir hale gelmesi sağlandı. Yazılımı 1.0 ile çağırmayı biz ne kadar uzun tutmaya çalışsak da, bir çok insan 1.0 sürümüne çıkmadan önce bile, Subversion'ı 1.0 sürüm numarası ile çağırıyordu. Şunun da farkındaydık ki, bir çok insan Subversion'ı kullanmak için 1.0 sürümünü bekliyordu ve yazılım hakkında bu sürüm etiketine bağladıkları çok farklı beklentileri vardı. Ve biz de bu standardı bozmadık.

  4. Subversion'ın istemci/sunucu uyumluluğunda izlediği yöntem nedir? [Y, A]

    İstemci ve sunucu tarafı sürüm numaralarının major kısmı aynı olacak şekilde uyumlu olduğunda çalışması düşünülüp, bu şekilde dizayn edilmiştir. Şöyle ki: 1.X sürümüne sahip bir istemci, 1.Y sürüm numaralı bir sunucu üzerinde çalışabilecektir. Fakat şu da unutulmamalıdır ki, sürüm numaraları farklı istemci ve sunucular arasındaki iletişimde bazı işlemlerin kullanılamayacak olması olasılığı vardır.

    Sunucu ve istemcinin birlikte işlerlik politikası HACKING dosyasının "Compatibility" (Uyumluluk) kısmında dökümante edilmiştir.

  5. Subversion hangi işletim sistemleri üzerinde çalışabilir? [Y, A]

    Tüm modern Unix, Win32, BeOS, OS/2, MacOS X türevlerinde çalışabilir.

    Subversion ANSI C ile yazılmış olup, APR (Apache Portable Runtime) kütüphanesini taşınabilirlik katmanı olarak kullanmaktadır. Bu nedenle Subversion, APR'nin çalıştığı her platformda (ki bu neredeyse tüm platformları kapsıyor) rahatlıkla çalışabilir. Subversion'ın sunucu (arşiv) tarafı ise dosya sistemi BDB olmadığı sürece Win9x platformlarda da çalışmaktadır. (Çünkü Berkeley DB'nin Win9x sistemlerdeki paylaşımlı bellek kısımlarında bazı sorunları var.) 1.1 sürümünde kullanılmaya başlanan FSFS arşivleri bu kısıtlamaya sahip değildir. Fakat Win9x sistemlerdeki dosya kilitleme mekazimasındaki bir kısıtlamadan dolayı FSFS de Win9x sistemlerde çalışmamakta. Ama FSFS için bu kısıtlamanın da 1.1.2 sürümünde ortadan kalkması için çalışılıyor.

    Toplamak gerekirse; Subversion istemcisi APR'nin çalıştığı her platformda; Subversion sunucusu ise yine, arşivi Win95/Win98/WinMe sistemlerde tutamasa bile, APR'nin çalıştığı her platformda çalışabilir.

  6. Bu yeni dosya sistemi nasıl bir şey? Ext2 benzeri bir şey mi yoksa? [Y, A]

    Hayır. "Subversion dosya sistemi" çekirdek seviyesinde, işletim sistemlerine kurulabilen bir dosya sistemi değildir. Bunun yerine, Subversion'ın arşiv dizaynı için kullanılan bir terimdir. Arşiv veritabanı üstüne kurulmuş olup, sürüm numaralarına sahip bir dosya sistemini taklit eden bir C API'si sunuyor. Bu yüzden arşive erişen bir yazılım yazmak, diğer dosya sistemleri için yapılanlara benzer. Normal bir dosya sistemi ile Subversion dosya sistemi arasındaki ana fark ise, Subversion dosya sisteminde, herhangi bir dosya/dizin yenisi ile değiştirilse ya da silinse dahi, arşivde kendine ait bir sürüm numarası ile varlığını korur.

  7. Subversion'ın bir Apache eklentisi olduğunu duydum. Subversion sunucular için ne kullanıyor? [Y, A]

    Hayır. Subversion bir çeşit kütüphaneler topluluğudur. Yanında bu kütüphaneleri kullanan bir komut satırı istemcisi ile gelir. İki çeşit Subversion sunucusu vardır: svnserve, cvs pserver benzeri, başlı başına tek bir sunucudur yada Apache httpd-2.0 ile mod_dav_svn modülü. svnserve özel bir protokol kullanırken, mod_dav_svn ağ protokolü olarak WebDAV kullanır. Daha fazla bilgi için Subversion kitabındaki 6. bölüme bakınız.

  8. Yani bu Subversion kullanmak için Apache yüklemek zorunda olduğum anlamına mı geliyor? [Y, A]

    Kısaca cevaplamak gerekirse: Hayır.

    Eğer sadece bir Subversion arşivine erişmek istiyorsanız, istemciyi kurmanız yeterli. Eğer ağdaki bir Subversion arşivine ev sahipliği yapmak istiyorsanız Apache2'yi ya da svnserve'ü kurmalısınız.

    Ağ üzerinden ulaşılabilir bir Subversion sunucusu kurmak için daha fazla bilgiye Subversion kitabındaki 6. bölümden ulaşabilirsiniz.

  9. Şu an Apache 1.x kullanıyorum ve Subversion arşivlerini sunmak için Apache 2.0 kuramam. Bu bir Subversion sunucusu çalıştıramayacağım anlamına mı geliyor? [Y, A]

    Hayır, Subversion sunucusu olarak svnserve kullanabilirsiniz. svnserve de çok iyi bir şekilde çalışıyor.

    Eğer WebDAV ve onun ile gelen diğer bir çok "eklenti"yi istiyorsanız, evet, o zaman Apache 2.0 kurmalısınız. Apache 2.0'ı başka bir port numarası üzerinde koştururken, Apache 1.x'i 80. port altında çalıştırmak daima bir seçenek olmuştur. Apache'nin farklı sürümleri aynı makine üzerinde sorunsuzca çalışabilmektedir. Yapmanız gereken tek şey httpd.conf dosyasındaki Listen ibaresinin karşısındaki 80 değerini 8080 gibi istediğiniz bir değer ile değiştirmek ve arşivinizin URL'sini doğru port değeri ile vermek. (Örn: http://svn.mydomain.com:8080/repos/blah/trunk/)

  10. Neden SCM'nin (Kaynak Kontrol Yönetimi [Source Control Management]) Y sistemi gibi bir X sistemi kullanmıyorsunuz? [Y, A]

    SCM sistemlerinde yeni bir çığır açma ya da piyasadaki tüm SCM'lerin en iyi özelliklerini toplama gibi bir niyetimiz yok. Yaptığımız tek şey CVS'in yerine bir şeyler oluşturmak. Lütfen ilk soruya bakınız.

  11. Neden tüm arşivim aynı revizyon numarasını paylaşıyor? Tüm projelerimin kendinlerine ait revizyon numaralarının olmasını istiyorum. [Y, A]

    Arşivdeki genel bir revizyon numarasının kullanıcının bakış açısından hiçbir anlamı yoktur. Bu şema tasarımının asıl hedefine ulaşmasını sağlayan bir iç mekanizmadır. Bu sayede kullanıcı herzaman saçma sapan uzun tarih/zaman katarları yazmaktan kurtarılmış olur.

    Revizyon numaraları sadece arşiv ve kullanıcı açısından kullanım kolaylığı ile ilgilidir. Bunun arşivde ne sakladığınız ile ilgili bir nedeni yoktur. Hatta arşivdeki revizyon numaraları projenin gerçek gelişimi hakkında isabetli bir tahmin yapmak için dahi yeterli değildir. Projenin gerçek gelişimi hakkında fikir sahibi olmanın çok daha karmaşık yolları vardır.

  12. Subversion `changeset' özelliğine sahip mi? [Y, A]

    Bu biraz yüklü bir soru. Çünkü "changeset" denildiği zaman neredeyse herkes ya farklı bir tanım ile yaklaşıyor ya da bir sürüm kontrol sistemi "changeset" özelliği sunduğu zaman herkesin beklentisi farklı oluyor.

    Bu ufak tartışmanın amacı doğrultusunda "changeset"in ufak bir tanımını şu şekilde verebiliriz: Tek bir etiket altındaki değişikliklerin bir toplamı. Değişiklikler düz bir metin dosyası üzerinde olabileceği gibi, dizin yapısındaki düzenlemeleri ya da metadata ayarlamalarını da içerebilir. Daha genel anlamda, "changeset" sadece etikete sahip bir yamadır (patch'dir).

    Subversion ilk sırada sürüm numaralarına sahip arşiv ağaçlarını yönetir (arşiv bu ağaçların toplamından oluşur) ve "changeset"ler de bu arada türetilir. Arch ya da BitKeeper gibi sistemlerde öncelik "changset"lerde olup (yani tüm arşiv bir yama deposudur) ağaç yapıları bu yamalar ile birlikte oluşturulur.

    Kesin olarak ifade edilmeye çalışıldığında iki felsefenin de eksileri ve artıları var: hesap 30 yıl öncesine kadar gidiyor. Her ikisinin de geliştirilecek olan yazılımın türüne bağlı olaraktan iyi ve kötü yanları var. Bunu burada tartışmayacağız. Onun yerine, Subversion ile neler yapabileceğiniz hakkında bir açıklama bulacaksınız burada.

    Subversion'da, global bir revizyon numarası olan 'N' arşivde bir ağacı etiketler ve bu sayede arşiv N. onaylamadan sonraki durumu görebilir. Bu ayrıca açıkca belirltilmiş bir "changeset"in de etiketidir: Eğer N. ağaç ile N-1. ağacı karşılaştırırsanız, bu iki ağaç arasındaki onaylanmış kesin farkların bir yamasını (patch'ini) elde edersiniz.

    Bu sebepten dolayı, "N. revizyon"un sadece bir ağaç olmadığı kolayca anlaşılabilir olup, bunun ayrıca bir "changeset" olduğu da açıkça görülebilir. Eğer projenizdeki hataları herhangi bir durum takip sistemi kullanarak tespit ediyorsanız, revizyon numaralarını size ilgili hataların yamalarını vermeleri için kullanabilirsiniz. Örnek verecek olursak: "Bu durum 9238. revizyonda düzeltildi." şeklinde açıklamaya sahip bir arşiv kaydının düzeltilmesi için ilgili "changeset"i svn log -r9238 çıktısı ile gördükten sonra, yamayı svn diff -r9237:9238 ile oluşturabilirsiniz. Buna ek olarak svn'nin merge komutu da revizyon numaralarını kullanır. Başka bir daldaki (branch'daki) değişiklikleri kendi dalınıza aktarmak içinse, diğer dalın URL'sini parametreler arasına eklemeniz yeterli: svn merge -r9237:9238. Artık #9238 "changeset"i de kendi çalışır kopyanıza eklenmiş oldu.

    Düşünüdüğünde bu "changeset"ler çevresine kurulmuş bir sistem için hiç de karmaşık değil, fakat hala CVS'e karşı uçsuz bucaksız bir kolaylık.

  13. Subversion'ın yeni sürümü ne zaman çıkacak? [Y, A]

    Proje durum sayfamıza bakabilirsiniz: http://subversion.tigris.org/project_status.html.

  14. Subversion 1.1 ve üstü sürümlerde normal svn add komutu ile sembolik bağlantılar (symlink) ekleyebilirsiniz.

    Ayrıntıda ise, Subversion'ın kendi tuttuğu arşiv için `symlink' kavramı yoktur. Onun yerine "versiyon numarasına sahip symlinkler"i "svn:special" özelliği ekleyerek normal bir dosyaymışcasına saklar. Unix istemcileri bu özelliği fark edip, çalışma kopyasında dosyayı bir sembolik bağlantıymışcasına gösterir. Win32 istemcilerinin sembolik bağlantı özelliği olmadığından dolayı dosyanın bir `symlink' olduğunu algılayamaz ve normal bir dosyaymışcasına gösterir.

  15. Subversion'ın logosunun vektörel biçimleri de mevcut olmak üzere, Subversion arşivinde logoların bulunduğu dizine bakabilirsiniz.

    Özel olarak logoların EPS ve Adobe Illustrator biçimleri de mevcut.

  16. Sormak istediğim başka sorularım var. Daha fazla bilgiye nereden ulaşabilirim? [Y, A]

    Lütfen merak ettiğiniz sorularınızı Subversion Kullanıcılar Grubunun e-posta listesine gönderiniz. Diğer bir seçenek olarak ise bir çok Subversion kullancısını aktif olarak bulabileceğiniz irc.freenode.net IRC sunucusundaki #svn kanalına bakabilirsiniz.

Nasıl ... yapabilirim?

  1. Subversion'ın kaynak kodunu nasıl kendi çalışma dizinime çekebilirim (`checkout' edebilirim)? [Y, A]

    Subversion istemcisini kullanarak aşağıdaki komutu vermeniz yeterli:

    $ svn co http://svn.collab.net/repos/svn/trunk subversion
    

    Bu sayede Subversion'ın kaynak kodununun bir kopyasını kendi makinenizdeki subversion dizini altına indirmiş olacaksınız.

  2. Nasıl bir arşiv oluşturup içine veri atabilirim? [Y, A]

    http://svn.collab.net/repos/svn/trunk/README adresine ya da özel olarak "Quickstart Guide"ın IV. bölümüne bakabilirsiniz.

    Hatta daha ayrıntılı bilgi için Subversion Kitabının 5. bölümüne göz atınız.

  3. Önceki bir CVS arşivimi, nasıl bir Subversion arşivine çevirebilirim? [Y, A]

    Bu iş için Subversion geliştirme ekibi üyeleri cvs2svn adından bir araç geliştirmiş ve halen de devamlılığını sağlaması için bakımını sağlamaktadır. cvs2svn'i http://cvs2svn.tigris.org/ adresinde bulabilirsiniz. Ama kullanmadan önce README dosyasını okuduğunuza emin olun.

    Eğer cvs2svn.py işinizi görmezse (örneğin arşiviniz üzerinde çevirme işlemi yaparken hata verip çıkıyorsa, ya da branch ve tag'ler ile sizin istediğiniz gibi işlem yapmıyorsa) kullanabileceğiniz başka 2 araç daha var. Tüm bu araçlar değişik özelliklere sahip (ve tabiki beraberinde içerdikleri değişik hatalar ile):

    Bunun dışında Subversion bağlantılarına da göz atınız.

  4. Ya eğer bir proxy arkasındaysam? [Y, A]

    Eğer Subversion istemcisinde doğru ayarları yapacak olursak, proxy arkasındayken de rahatlıkla çalışabilirsiniz. İlk önce "servers" ayar dosyanız üzerinde gerekli değişiklikleri kullanacağınız proxy'ye göre yapın. Ayar dosyanın bulunduğu dizin kullandığınız işletim sistemien göre değişir. Linux ya da Unix sistemlerde "~/.subversion" dizini altinda bulabilirsiniz ayar dosyasını. Windows sistemlerde ise "%APPDATA%\Subversion" dizini altında. ("echo %APPDATA%"yu deneyin, fakat unutmayın ki bu gizlenmiş bir dizindir.)

    Dosyanın içinde açıklayıcı yorum satırları ne yapmanız gerektiğini zaten yazar. Eğer bu dosyanız yoksa, en son Subversion istemcilerinden birini indirip herhangi bir Subversion komutu çalıştırın; bu sayede ayar dizinleri ve şablon dosyaları otomatik olarak oluşturulmuş olacaktır.

    Eski Subversion sürümleri, 0.14.3 bootstrap paketi de dahil olmak üzere, bu dosyanın yerine "~/.subversion/proxies" kullanırlar. Bu eski dosya şuanki Subversion tarafından gözardı edilmektedir.

    Bir sonraki adımda, proxy sunucunuzun Subversion tarafından kullanılan tüm HTTP metodlarını desteklediğine emin olun. Bazı proxy sunucuları şu metodları öntanımlı olarak desteklememektedir: PROPFIND, REPORT, MERGE, MKACTIVITY, CHECKOUT. Genel olarak, böyle bir sorunu çözmek ise kullandığınız proxy sunucusu yazılımı ile ilgilidir. Squid için ayar dosyası şu şekilde olacak:

    #  TAG: extension_methods
    #       Squid only knows about standardized HTTP request methods.
    #       You can add up to 20 additional "extension" methods here.
    #
    #Default:
    # none
    extension_methods REPORT MERGE MKACTIVITY CHECKOUT
    

    (Squid'in 2.4 ve üstü sürümleri zaten PROPFIND'ı desteklemektedir.)

    Ek olarak "Subversion kullandığı tüm HTTP metodları neler?" başlıklı soruya proxy sunucunuzdan kullanabileceğiniz HTTP metdoları ile ilgili olarak daha fazla ayrıntı için bakabilirsiniz.

    Eğer Subversion trafiğinizi proxy'den geçirmek çok zor ya da imkansızsa ve hala Subversion kodlarını `checkout' etmek istiyorsanız proxy'nin etrafından dolanabilirsiniz. 80. portu filtreleyen bazı proxy sunucular yine de 81. porta hiçbir kısıtlama getirmezler. Bu nedenden dolayı, svn.collab.net arşiv sunucusu hem 80. portu hem de 81. portu dinlemektedir. Yani alternatif olarak şunu da deneyebilirsiniz:

    $ svn checkout http://svn.collab.net:81/repos/svn/trunk subversion
    

    ve belki bu sayede proxy'yi atlatmayı başarırsınız. Bir diğer strateji olarak `checkout' işlemini SSL üzerinden gerçekleştirmek olabilir (ki çoğu proxy yazılım buna izin vermektedir):

    $ svn checkout https://svn.collab.net/repos/svn/trunk subversion
    

    Elbette bunu yapmak için Subversion istemcinizin SSL desteği ile kurulmuş olması lazım. Bunu yapmak için ./configure esnasından --with-ssl desteğini vermeniz yeterli. Kurulu Subversion istemcinizin SSL destekleyip desteklemediğini öğrenmek için ise svn --version komutunu deneyebilirsiniz.

  5. Sistem yöneticilerim Subversion için bir HTTP sunucu kurmama izin vermiyor? Uzaktan erişim istiyorsam başka bir yolum var mı? [Y, A]

    Bir seçenek olarak Apache yerine svnserver kullanmak olabilir. Ayrıntılı bilgi için Subversion kitabının 6. bölümüne göz gezdirebilirsiniz.

    Fakat şu da var ki, eğer sistem yöneticileriniz sizin Apache çalıştırmanızı izin vermiyorsa, 3690. porttan başka bir sunucu çalıştırmanıza da büyük bir ihtimalle izin vermeyeceklerdir. Bundan sonra cevabın kalan bölümü sistem yöneticilerinizin var olan bir SSH altyapısını kullanmanıza izin veriyor olup olmamasından ibaret.

    Eğer daha önceden CVS kullandıysanız, CVS sunucusuna bağlanmak için SSH kullanmış olmanız lazım. ra_svn Subversion bağlantı metodunu kullanmak da bunun ile birebir. Sadece "svn+ssh" ön ekini arşiv URL'nize eklemeniz yeterli:

    $ svn checkout svn+ssh://your.domain.com/full/path/to/repository
    

    Bu sayede SSH ile karşı tarafta, sizin UID'iniz ile giriş yapılan, özel bir svnserve işlemi başlatmış olup, tüm veri aktarımını şifrelenmiş bir kanal üzerinden gerçekleştirmiş olursunuz.

    Bir diğer çözüm yolu olarak SSH port yönlendirmesini arkamıza alarak korunan sunucuya ra_dav ile bağlanmak. Firewall'unuzun arkasında sizin arşivinize bağlanabilen bir makineye SSH ile bağlanmalısınız. Dikkat ederseniz bağlandığınız SSH sunucusu sizin arşivinizin bulunduğu makinede değil. Orada da olabilir, ama olmak zorunda da değil.

    Daha sonra bulunduğunuz makineden sizin arşivinizi sunan HTTP sunucusuna bir port yönlendirmesi tanımlamanız gerekli. Daha sonra Subversion arşivinize bu yerel porttan rahatlıkla bağlanabilirsiniz. Ardından, istekleriniz Subversion arşivinize bu SSH sunucusu sayesinde kanal aracılığıyla iletilecektir.

    Örnek olarak: Bir Subversion ra_dav kurulumu şirket firewall'unuzun arkasındaki 10.1.1.50 makinesinde olsun (buna svn-server.example.com diyelim). Şirketiniz dış dünya tarafından kullanıma açık ssh-server.example.com'a SSH üzerinden bağlantıya izin veriyor olsun. Artık firewall arkasındaki arşivinize http://svn-server.example.com/repos/ours'den erişebilirsiniz.

    Örnek: İstemci ssh sunucusuna port yönlendirmesi ile bağlanalım ve port yönlendirmesini kullanarak arşivi "checkout" edelim:

    $ ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com
    $ svn checkout http://localhost:8888/repos/ours
    

    Şu da var ki svn-server.example.com httpd işlemini hakları kısıtlanmış bir kullanıcı ile çalıştırıyor olabilir. Bu durumda Subversion sunucunuz root bağlantısına ihtiyaç duymamış olacak.

    Joe Orton şunu ekler:

    Subversion sunucusu MOVE ve COPY isteklerindeki "Destination" başlığında
    yer alan sunucu adına karşı hassatır. Bu yüzden bu noktada biraz dikkatli
    olmanız gerekmekte - bir "ServerAlias localhost" ibaresi her şeyin yolunda
    çalışması için gerekli.
    

    SSH port yönlendirme ile ilgili bazı bağlantılar:

  6. Subversion altında birden fazla projeyi nasıl yönetebilirim? [Y, A]

    Bu ilgilendiğiniz proje bağlı. Eğer projeler birbirleri ile ilgiliyse ve kendi aralarında veri paylaşıyorlarsa, en iyisi ikisini tutan bir çok alt dizinden oluşmuş tek bir arşiv oluşturmak olur. Şunun gibi:

    $ svnadmin create /repo/svn
    $ svn mkdir file:///repo/svn/projA
    $ svn mkdir file:///repo/svn/projB
    $ svn mkdir file:///repo/svn/projC
    

    Eğer projeler birbiri ile tamamen ilişkisizse ve aralarında bir veri paylaşımı olmayacak gibi görünüyorsa, bu durumda herbir proje için kendine ait ayrı bir arşiv oluşturmak en iyisi olacaktır:

    $ mkdir /repo/svn
    $ svnadmin create /repo/svn/projA
    $ svnadmin create /repo/svn/projB
    $ svnadmin create /repo/svn/projC
    

    (Ben Collins-Sussman <sussman@collab.net> açıklandığı gibi) Bu iki yaklaşım arasındaki fark ise şu şekilde:

  7. Birbirinden tamamen farklı iki arşivi nasıl birleştirebilirim? [Y, A]

    Eğer arşivlerden birinin geçmişi önemli değilse, diğer projenin altında yeni bir dizin oluşturup, bunu oraya atabilirsiniz.

    Eğer iki projenin de geçmişi sizin için önemliyse, birini `svnadmin dump' ile yedekledikten sonra, bu yedeği `svnadmin load' ile diğerini içine atabilirsiniz. Revizyon numaraları kaybolacak, fakat projelerin geçmişi korunmuş olacak.

    Peter Davis <peter@pdavis.cx> bu konu ile ilgili svn'in CVS modüllerindeki kullanımına benzer bir yöntem anlatıyor:

    Eğer söz konusu olan ayrı ayrı iki farklı dizin ağaçlarının aynı arşivde birleştirilmesi ise, svn'in CVS modül versiyonlarını kullanabilirsiniz.

    Bir dizin üzerindeki svn:externals değişkenini orjinal arşiv `checkout' edilmeye çalışıldığında diğerlerinin de otomatik olarak `checkout' edilebileceği şekilde ayarlayınız. Diğer arşiv hala ayrı gözükürken, elinizdeki çalışma kopyasında ikisi de `merge' edilmiş gözükecektir. Eğer `checkout' ettiğiniz arşivde bir değişiklik onaylatmak isterseniz de bu diğer bağladığımız arşivi de etkileyecektir.

    `merge` işlemi tam olarak o kadar da net değildir: Çekim işlemi sadece çalışan örnekleri etkileyecektir, bu yüzden ikinci arşivden çekilmiş olan modüllere ulaşmak istediğinizde birinci adresin URL'sini kullanamayacaksınız. İkiside ayrı URL'de kalmışlardır.

  8. Arşivimi ya da elimdeki çalışma kopyamın yedeğini bir NFS sunucu üstünde tutmalı mıyım? [Y, A]

    Eğer arşivinizi Berkeley DB üstünde tutuyorsanız (ki öntanımlı olarak Berkeley DB kurulur dosya sistemi olarak) arşivinize NFS üzerinde erişmeyiniz. BDB veritabanının uzaktaki bir dosya sisteminde tutulmasına desteklememektedir. Bazı NFS sunucuları NFS ile bağlanmış disk bölümlerinde BDB desteklediklerini iddaa etseler de, bu konuda gördüğümüz tek şey NFS ya da SMB ağı ile bağlı BDB veritabanlarında veri bozukluğu.

    Eğer arşiviniz bir FSFS dosya sistemi kullanıyorsa, bunu (kitleme (locking) özelliği destekleyen) modern bir NFS sunucu üzerinde tutmanız da bir sorun olmaz.

    Çalışan örneklerde NFS üzerinde tutulabilir (çok rastlanan bir senaryo olan ev dizininiz bir NFS sunucuda tutuluyorsa gibi). Linux NFS sunucularında, Subversion içinde yeniden adlandırma işlemleri çok yüklü olduğu için bir arşivi `checkout' ederken bazı kullanıcıların dediğine göre alt dizinlerin alımı (subtree checking) özelliği kapalı olmalıymış (ki öntanımlı olarak açık gelir). NFS sunucularında alt ağaç alımının kapatılmasının nasıl olacağı hakkında ayrıntılı bilgi için NFS Sunucu Kılavuzu ve exports(5)a göz atabilirsiniz.

    SMB üzerinde arşiv çekimi yapılmaya çalışıldığında verinin bozulduğu şeklinde en az bir tane hata raporu aldık. Sorudaki sunucu Samba'nın eski bir sürümüydü (2.2.7a). Samba'nın yeni sürümü (3.0.6) ile bu sorun tekrarlanmadı.

  9. Neden arşivim çok yer kaplıyor? [Y, A]

    Arşiv tüm verinizi bir Berkeley DB ortamı altında repos/db/ dizininde saklar. Burada bir çok tablo ve log dosyası (log.*) topluluğu bulunmaktadır. Berkeley DB bütün bu tablolardan yapılan değişikliklerin kaydını tutar, ve bu sayede herhangi bir kesinti esnasında veri kurtarılabilir. (Daha fazla bilgi.)

    Eğer log dosyaları hakkında bir şey yapmazsanız, sürekli değişikliklerin kaydını tutarak, bir çok disk alanı tutacak şekilde büyüyecektir. İstenilen herhangi bir anda Berkeley DB aslında sadece bir kaç log dosyasına ihtiyaç duyar (Şu mesaja ve devamına bakınız); geri kalan rahatlıkla silinebilir. Eğer tüm log dosyalarını sonsuza kadar koruyacaksanız, Berkeley DB teorik olarak oluşumunun ilk anından sunsuza kadar tüm değişiklikleri kaydedecektir. Fakat pratikte, eğer yedek alıyorsanız, bu harcadığı disk alanına değmeyecektir.

    svnadmini kullanarak hangi log dosyalarının silinebileceğini görebilirsiniz. Bunu yapacak bir cron görevi dahi atayabilirsiniz.

    $ svnadmin list-unused-dblogs /repos
    /repos/db/log.000003
    /repos/db/log.000004
    [...]
    $ svnadmin list-unused-dblogs /repos | xargs rm
    # disk space reclaimed!
    

    Ayrıca Berkeley DB'nin db_archive komutunu da kullanabilirsiniz:

    $ db_archive -a -h /repos/db | xargs rm
    # disk space reclaimed!
    

    Ayrıca svnadmin hotcopy ya da hotbackup.py'ye de göz atınız.

    Not: Berkeley DB 4.2, Subversion 0.35 ve üzerinde yeni oluşturulan arşivlerde otomatik log dosyası silme işlemi etkin haldedir. Bunu kullanmak için svnadmin create komutuna --bdb-log-keep parametresini eklemeniz yeterli. Berkeley DB kılavuzundaki DB_LOG_AUTOREMOVE kısmına göz atabilirsiniz.

  10. Arşiv izinlerini nasıl doğru bir şekilde ayarlayabilirim? [Y, A]

    Mümkün olduğu kadar az kullanıcının arşiv üzerinde yetkisi olmasını sağlayın. Örnek olarak, apache ya da svnserve -d komutunu özel bir kullanıcı ile başlatın ve tüm arşiv yetkisini bu kullanıcıya verin. Bu kullanıcı dışında başka hiçbir kullanıcının arşive file:/// şeklinde bir URL kullanarak erişimini kısıtlayın ve svnlook, svnadmin ile arşiv üzerinde işlem yapmaya çalışırken, haklar tahsis ettiğimiz o özel kullanıcı ile bu komutları çalıştırdığınızdan emin olun.

    Eğer istemciniz arşive file:/// veya svn+ssh:// URL'leri ile ulaşıyorsa, o zaman birden fazla kullanıcının arşive erişiminden kurtulamayız. Bu durumda, 6. bölümdeki son kısma bakın ve en altta yer alan "checklist" kenar çubuğuna dikkat edin. Bu senaryoyu daha güvenli bir hale getirmek için atmanız gereken bir kaç adımın altını çiziyor.

    SELinux / Fedora Core 3+ / RedHat Enterprise kullanıcıları için not:

    Normal Unix izinlerine ek olarak SELinux altında her dosya, dizin, işlem için bir `güvenlik bağlamı' (security context) vardır. Bir işlem herhangi bir dosyaya erişmeye çalıştığında, sistem normal dosya izinlerinin ötesinde dosyanın ve işlemin güvenlik bağlamlarının uyumlu olup olmadığı yönünde kontrol yapar.

    Fedora Core 3'de diğer sistemlerin aksine SELinux yüklü ve ayarlı olarak gelir, ki bu nedenle Apache çok kısıtlı haklar altında çalışır. Subversion'ı Apache altında çalıştırabilmek için arşivin güvenlik bağlamlarını Apache'nin erişebileceği şekilde ayarlamanız gerekmekte. chcon komutunu güvenlik bağlamlarını ayarlamakta kullanabilirsiniz (chmod komutunda hakları ayarlamaya benzer şeilde). Örnek vermek gerekirse: Kullanıcılardan biri şu komutu çalıştırmalıdır:

    $ chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY
    

    ki güvenlik bağlamı arşive ulaşabilecek şekilde ayarlansın.

  11. Neden `read-only' işlemler için de arşive yazma izni gerekiyor? [Y, A]

    Çoğu istemci işlemi sadece okumadan ibarettir ("read-only"dir); `checkout' ya da `update' gibi. Bir erişim kontrol perspektifinden, apache de hepsini bu şekilde görür. Ama libsvn_fs (arşiv dosya sistem API'si) hala herhangi bir veri üretmek için arşive geçici yazma işlemi yapmak zorundadur. Bu nedenle arşive erişen tüm işlemler, Berkeley DB dosyalarına erişip onları kullanabilmek için, hem yazma hem de okuma işlemi yapmak zorundadır.

    Özel olarak, arşiv çok fazla "read-only" işleme iki ağaç yapısını karşılaştırarak cevap verir. Ağaçlardan biri genellikle HEAD revizyonudur ve diğeri de sıklıkla geçici bir `transaction' ağacıdır, ki bu nedenle bir yazma işlemine ihtiyaç duyulur.

    Bu kısıtlama sadece bdb altyapısına aittir, FSFS altyapısında böyle bir kısıtlama yoktur.

  12. Bir dosyayı arşivden nasıl tamamen silebilirim? [Y, A]

    Bazı özel durumlar vardır, bir dosya ya da onaylamanın tüm kayıtlarını ortadan kaldırmak isterseniz. (Belki birisi yanlışlıkla kişisel bir dosya onaylatmıştır.) Bu o kadar kolay değildir, çünkü Subversion kastılı bir şekilde bir verinin asla kaybolmaması için dizayn edilmiştir. Revizyonlar, biri diğerinin üzerine eklenen değişmez ağaç yapılarıdır. Herhangi bir revizyonu geçmişten silmek, domino taşı etkisi yaratacaktır; tüm onun üstüne yığılmış diğer revizyonlarda bir karmaşaya sebep olup büyük olasılıkla "checkout" edilmiş arşiv örneğinizi de geçersiz hale sokacaktır.

    Fakat Subversion'ın ilerisi için svnadmin obliterate komutu altında böyle bir planı var. (Bkz. Hata Raporu 516.)

    Şu an için ise tek bir çözüm yolunuz var: Arşivinizin svnadmin dump ile bir yedeğini aldıktan sonra buna svndumpfilter uygulayarak istenmeyen dizini dışladıktan sonra svnadmin load ile yeni bir arşivin içine atmak. Subversion kitabının 5. bölümüne daha ayrıntılı bilgi için bakabilirsiniz.

  13. Onaylanan bir değişikliğin log mesajını daha sonradan nasıl değiştirebilirim? [Y, A]

    Log mesajları arşivde herbir revizyona iliştirilmiş özellikler olarak saklanırlar. Öntanımlı olarak, log mesajı özelliği (svn:log) bir kere onaylandıktan sonra değiştirilemez. Bunun nedeni (svn:log gibi) revizyon özelliklerine yapılan değişiklikler, bu özelliğin önceki değerinin tümüyle yok sayılmasına yol açar ve Subversion bunu yanlışlıkla yapmanızı engellemek için deaktif etmiştir. Bunun yanında, revizyon özelliklerini değiştirmek için Subversion'da kullanabileceğiniz bir kaç yöntem mevcut.

    İlk yöntem olarak arşiv yöneticisi revizyon özelliklerinin değiştirilebilir olmasını sağlayabilir. Bunu "pre-revprop-change" adında bir askı ile yapabilir. (Bkz. Subversion Kitabı, 5. Bölümün ilgili kısmı.) "pre-revprop-change" askısı revizyon özelliğinin değişmemiş haline ulaşıp onu bir şekilde koruyabilir. (Örneğin, e-mail atarak.) Bir kere revizyon özelliklerinin değiştirilmesi etkinleştirildiğinde, bunu --revprop parametresini svn propedit ya da svn propset komutuna ekleyerek aşağıdaki yöntemlerden biri ile yapabilirsiniz:

    $ svn propedit -r N --revprop svn:log URL
    $ svn propset -r N --revprop svn:log "new log message" URL
    

    Burada N revizyon numarasını, URL ise arşiv adresini belirtiyor. Eğer bu komutu çalıştığını kopyanın içinde giriyorsanız URL kısmını yazmanıza gerek yok.

    Bir log mesajını değiştirmenin ikinci bir yolu ise svnadmin setlog komutunu kullanmak. Bunu arşivin dosya sistemindeki yerini belirterek yapabilirsiniz. Uzaktaki bir arşivi bu komut ile değiştiremezsiniz.

    $ svnadmin setlog REPOS_PATH -r N FILE
    

    Burada REPOS_PATH arşivin yeri, N revizyon numarası ve FILE da yeni log mesajının bulunduğu dosya. Eğer "pre-revprop-change" askısı yoksa (ya da bu askıyı bir sebepten dolayı geçmek istiyorsanız), --bypass-hooks parametresini kullanabilirsiniz. Eğer bu paramtereyi kullanacaksanız çok dikkatli olun. E-Mail ile haber verme ya da revizyon numaralarının kaydını tutan yedek alma askılarını da atlıyor olabilirsiniz.

  14. Subversion için yazdığım bir yamayı nasıl onaylatabilirim? [Y, A]

    İlk olarak, HACKING dökümanını okuyunuz.

    Bunu tam olarak anladıktan sonra, dev listesine başlığı [PATCH] kelimesi ile başlayıp tek satırlık bir açıklama ve mesajın içinde ilgili yamanızı içeren bir e-mail atınız (Eğer MUA'nız bunu `spam' olarak görmezse). Sonra geliştiricilerden biri yamanızı alıp (üstünde gerekli değişiklikleri yaptıktan sonra) uygulayıp, sonucu kontrol edecektir.

    Basit olarak izleyeceğiniz adımlar şu şekilde olacak:

    $ svn co http://svn.collab.net/repos/svn/trunk subversion
    $ cd subversion/www
    
    	[ make changes to faq.html ]
    	
    $ svn diff faq.html > /tmp/foo
    $ Mail -s "[PATCH] FAQ updates" < /tmp/foo
    

    Elbette gönderdiğniz e-mail yamanızı ne yaptığını hakkında uzun ve tatmin edici bir açıklama içerecek, HACKING dökümanında da yazdığı gibi, ki siz bunu zaten okudunuz, değil mi?

  15. Arşivde belirli bir yere nasıl aktarma (`import') işlemi gerçekleştirebilirim? (Orjinal arşiv kopyasında herhangi bir yerdeğiştirme ya da silme işlemi yapmadan, sıfırdan bir arşiv kolu oluşturmak gibi.) [Y, A]

    Örnek vermek gerekirse, /etc dizininin bir kısmını arşivinizin altında versiyon kontrolü için saklayacağımızı varsayalım:

    shell# svn mkdir file:///root/svn-repository/etc \
    > -m "Arşivde /etc'ye karşılık gelecek bir dizin oluştur."
    shell# cd /etc
    shell# svn checkout file:///root/svn-repository/etc .
    shell# svn add apache samba alsa X11 
    shell# svn commit -m "Ayar dosyalarımın ilk sürümü."
    

    Bu şekilde svn checkout komutunun şık bir özelliğinden yararlanmış oluyoruz: Arşivden belirli bir dizini, /etc altında zaten varolan bir dizine açıyoruz. İlk önce arşivimizde etc başlığında bir dizin oluşturduk ve /etc sanki bir nroaml bir çalışan kopyaymışcasına, arşivimizin etc dizinini /etc'ye `checkout' ettik. Bunu bir kere yaptıktan sonra, svn add komutunu kullanarak arşive istediğiniz dosya ya da dizini ekleyebilirsiniz.

    1328 nolu hata raporunda `import' edilen bir dizinin direk çalışan bir arşiv kopyasına tomatik olarak çevrilebilmesi şeklinde de bir istek var.

  16. Bazılarının Subversion sunucularını yükseltirken bahsettikleri "dök/yükle (`dump/load') döngüsü" tam olarak ne anlama geliyor? [Y, A]

    Subversion'ın arşiv veritabanı şeması gelişim sürecinde sık sık değişti. Subversion'ın pre-1.0 sürümü ile oluşturulmuş eski arşiveler bir üst sürüme güncellenmek istendiğinde aşağıdaki işlemlere ihtiyaç duyabilirler. Eğer Subversion'ın X ve Y sürümleri arasında bir veritabanı şeması değişikliği olmuşsa, arşiv yöneticileri Y sürümüne güncelleme işlemini şu şekilde yapabilirler:

    1. svnserve, Apache'yi ve arşive erişen diğer ne varsa kapatın.
    2. svnadmin'in X sürümünü kullanarak aşağıdaki komutu çalıştırın:
      shell# svnadmin dump /path/to/repository > dumpfile.txt
      
    3. shell# mv /path/to/repository /path/to/saved-old-repository
      
    4. Şimdi kurulu Subversion'ı X sürümünden, Y sürümüne (derleyerek ya da kurarak) yükseltin.
    5. Subversion'ın yeni kurulu Y sürümü ile aşağıdaki komutu çalıştırın:
      shell# svnadmin create /path/to/repository
      
    6. Yine Y sürümü ile:
      shell# svnadmin load /path/to/repository < dumpfile.txt
      
    7. Tüm askı betiklerini ve diğer şeyleri eski arşivden yenisine kopyalayın.
    8. svnserve, Apache ve diğerlerini baştan başlatın.

    `dump' ve `load' işlemleri hakkında daha ayrıntılı bilgi için http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4 adresine bakınız.

    Not: Çoğu yeni Subversion sürümü bir `dump' ve `load' işlemini aslında gerektirmemekte. Eğer böyle bir gereksinim doğarsa, bunu duyurularda ve CHANGES dosyasında göze çarpan bir şekilde belirtiriz. Eğer böyle bir uyarı ibaresi ile karşılaşmazsanız, herhangi bir `dump/load' işlemine ihtiyacınız yok demektir.

  17. İstemcilerin bir SSPI kimlik denetimi kullanarak Windows `domain controller'dan sisteme giriş yapmalarını nasıl sağlayabilirim? [Y, A]

    TortoiseSVN Windows sistemlerde Subversion kurulumu ile ilgili çok güzel bir dökümana sahip. http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch03.html#tsvn-serversetup-apache-5 adresindeki SSPI ile kimlik kontrolü kısmına bakınız.

    Bu dökümanın eski bir versiyonunda şöyle bir eksik satır var:

    SSPIOfferBasic On
    

    Bu satır olmadan, bir tarayıcı kullanıcıdan kimlik bilgilerini isteyecekken, bir Subversion istemcisi bunu yapmayacaktır. (Bir tarayıcı SSPI kimlik kontrolünden anlıyor, fakat NEON - Subversion'ın HTTP kütüphanesi - sadece basit kimlik kontrolünü anlayabiliyor.) İstemci hiçbir zaman kimlik kontrolü için sormayacağından, kimlik kontrolü isteyen herhangi bir işlem geçersiz olacaktır. Bu satır sayesinde mod_auth_sspi istemci ile basit kimlik kontrolü kullanacak, fakat kimlik doğrulaması için Windows `domain controller'dan faydalanacak.

  18. ".svn" dizin isimleri hoşuma gitmedi; "SVN" tarzı bir şeyi daha çok tercih ederdim. Bunu nasıl değiştirebilirim? [Y, A]

    Önerimiz, eğer yapabiliyorsanız ".svn" kullanmanız yönünde olacak. Eğer değiştirecek olursanız, sizin kullandığınız Subversion istemcisinden başkasını kullananlar için sorun çıkabilir. Eğer yapmak zorunda iseniz, subversion/include/svn_wc.h dosyasındaki

    #define SVN_WC_ADM_DIR_NAME   ".svn"
    

    satırını

    #define SVN_WC_ADM_DIR_NAME   "SVN"
    

    satırı ile değiştirip, Subversion'ı yeniden derlemeniz yeterli.

  19. Bir dosyanın büyük-küçük harfini nasıl değiştirebilirim? [Y, A]

    Bu problem iki durumda çıkıyor. Eğer dosyalarınızı dosya sistemi büyük-küçük harf duyarsız bir işletim sisteminde, Windows gibi, ekliyorsanız kendinizi herhangi bir dosyayı yanlış harf kullanarak yazmış bulabilirsiniz. Alternatif olarak, bir dosya isminin harflerinin büyük-küçüklüğünü değiştirmek istemiş olabilirsiniz.

    Eğer büyük-küçük harf duyarlı bir dosya sisteminde çalışıyorsanız, bu zaten bir sorun oluşturmayacaktır. Dosyayı yeni ismine taşımanız yeterli:

    svn mv file.java File.java
    

    Fakat bu büyük-küçük harf duyarsız bir işletim sisteminde çalışmayacaktır. Windows'da bunu başarmak için, dosyayı geçici bir yere kopyalarsanız, ardından arşivdekini sildikten sonra bunu tekrar yerine koyarsınız. Ya da daha iyi bir yöntem olarak Subversion URL'lerini kullanarak dosyanın yerini değiştirmek suretiyle yeniden adlandırabilirsiniz. Bu sayede boş yere geçmiş kayıtlarında yer harcamamış olup anında istediğiniz hale gelecektir.

    İki yöntem de Windows'daki çalışan kopyalarınızı problemli bırakacaktır; çünkü, Windows dosyaları güncellemeye çalıştığında dosya isimlerini birbirine karıştırabilir. (Şöyle bir mesaj alacaksınız: svn: Failed to add file 'File.java': object of the same name already exists.) Eğer bunu yapmak istemiyorsanız, iki adımdan oluşan bir işlem gerçekleştirmelisiniz.

    Harfleri yanlış yazımlış her dosya için, şu komut harfleri değiştirecektir:

    $ svn mv svn://svnserver/path/to/file.java svn://svnserver/path/to/File.java
    

    Çalışan örneği güncellemek için, ilgili dizine geçin ve şunu yapın:

    $ svn update file.java
    $ svn update
    

    İlk güncelleme file.java dosyasını kopyanızdan silecek, ikincisi ise File.java'yı ekledikten sonra sizi elinizde doğru çalışır bir kopya ile bırakacak. Eğer çok fazla problem yaratan dosyanız varsa, şunu da deneyebilirsiniz:

    svn update *
    svn update
    

    Gördüğünüz üzere, yanlış harf ile girilen bir dosyayı, büyük-küçük harf duyarsız bir dosya sisteminde düzeltmek oldukça meşakkatli bir iş. Elinizden geldiğince dosyayı ilk oluşturduğunuzda doğru karakterler ile oluşturmaya çalışın.

  20. Birleştirme (`merge') işlemi için CVS'de kullandığım `tag'ları kullanabilir miyim? [Y, A]

    Aşağıda da gösterildiği gibi, birinin revizyon numarasını hatırlamanıza gerek kalmadan da bir `branch' arşiv yığınına `merge' edilebilir. Ya da tersi (bu, aşağıdaki örnekte gösterilmemiştir).

    Aşağıdaki örnekte içinde foo adlı değiştirmek istediğimiz dosyanın bulunduğu bar adında bir `branch'ın, var olan arşiv depomuz olan /home/repos'da nasıl oluşturulacağı anlatılıyor.

    `brach' `merge'lerini izlemek için, arşivde tags/branch_traces/ `tag'leri saklamak için kuruldu.

    # setup branch and tags
    $ svn copy file:///home/repos/trunk \
    >          file:///home/repos/branches/bar_branch \
    >          -m "start of bar branch"
    $ svn copy file:///home/repos/branches/bar_branch \
    >          file:///home/repos/tags/branch_traces/bar_last_merge \
    >          -m "start"
    
    # checkout branch working copy
    $ svn checkout file:///home/repos/branches/bar_branch wc
    $ cd wc
    
    # edit foo.txt file and commit
    $ echo "some text" >> foo.txt
    $ svn commit -m "edited foo"
    
    # switch to trunk and merge changes from branch
    $ svn switch file:///home/repos/trunk
    $ svn merge file:///home/repos/tags/branch_traces/bar_last_merge \
    >           file:///home/repos/branches/bar_branch
    
    # Şimdi 'foo.txt' içeriğini kontrol edin,
    # değişiklikleri içeriyor olmalı.
    
    # commit the merge
    $ svn commit -m "Merge change X from bar_branch."
    
    # Son olarak, son durumu yansıtması için izlemek
    # için kullandığımız `trace' `branch'ını güncelliyoruz.
    $ svn delete -m "Remove old trace branch in preparation for refresh." \
    >            file:///home/repos/tags/branch_traces/bar_last_merge
    $ svn copy file:///home/repos/branches/bar_branch \
    >          file:///home/repos/tags/branch_traces/bar_last_merge \
    >          -m "Reflect merge of change X."
    
  21. Neden $Revision$ anahtar değişkeni değer olarak dosyanın değiştirilmiş son revizyon numarasını alıyor; halbuki ben o anki geçerli sürüm numarasını almasını istiyorum. [Y, A]

    Subversion arşivin revizyon numarasını tüm genel itibariyle arttırdığı için, herhangi bir anahtar kelimenin bu numara yerine geçmesi mümkün değildir. Aksi halde her güncelleme ya da onaylamadan sonra elinizdeki kopyada yer alan tüm örnekler teker teker taranıp, muhtemelen de değiştirmeli.

    İstediğiniz bilgiye (elinizdeki kopyanın revizyon numarasına) svnversion komutu ile ulaşabilirsiniz. Bunun ile belirttiğiniz kopyanın revizyon numarası hakkında bilgi sahibi olabilirsiniz. (Bkz. svnversion --help)

    Windows kullanıcıları TortoiseSVN yükleme sayfasından SubWCRev.exe programını indirebilirler. Bunu kullanarak belirtilen bir dosyadaki tüm $WCREV$ `tag'larını o anki kopyanızın revizyon numarası ile değiştirebilirsiniz.

  22. Subversion da CVS'deki $Log$ gibi bir anahtar değişkene sahip mi? [Y, A]

    Hayır. CVS'deki $Log$ anahtar kelimesi için bir karşılık yok. Eğer belirli bir dosyanın log'una ulaşmak istiyorsanız, svn log your-file-name ya da svn log url-to-your-file komutlarını kullanabilirsiniz. Posta listesinden, $Log$'un neden kötü olduğuna dair bir kaç açıklama:

    `branch'ler arası değişikleri `merge' etmeye başladığınız andan itibaren,
    $Log$ tam bir felaket haline geliyor. Bu anahtar kelimenin doğası gereği
    otomatik olarak kolayca çözülemeyen uyuşmazlıklar pratik olarak
    garantilenmiştir.
    

    Ve:

    Subversion log mesajları, svn:log revizyon özelliği sayesinde,
    değiştirilebilir değerlerdir. Bu nedenle herhangi bir dosyada $Log:$ yerine
    yazılmış olan değerinin tarihi geçmiş olabilir. İlgili dosya değişmemiş olsa
    bile $Log:$'un geçtiği her yerde girilmiş olan değer ileride değiştirilmek
    zorunda kalınabilir.
    

    Umrumda bile değil. Her ne olursa olsun ben kullanmak istiyorum. Bir sonraki sürüme böyle bir özellik ekleyecek misiniz?

    Hayır. Bu sürümü eklemek ya da eklenmesi için gerekli yama gönderilse bile, bu yamayı onaylamak gibi bir planımız yok henüz. Eğer dosyalarınızı log mesajları ile dağıtmak istiyorsanız, kurulu sisteminizin imkanları doğrultusunda bunun ile uğraşabilirsiniz.

  23. Projemdeki bir dosyanın yerel kullanıcılar tarafından paylaşılabilmesini, ama yapılan değişikliklerin arşive asla geçirilememesini istiyorum. Bu dosya için `svn commit'i nasıl etkisiz hale getirebilirim? [Y, A]

    Cevap: Dosyayı versiyon kontrolü altına koymayın. Bunun yerine versiyon kontrolüne file.tmpl gibi bir template (şablon) koyun.

    Ardından, başlangıç svn checkout'un ardından, kullanıcılarınızın (ya da kurulu sisteminizin) normal bir OS kopyalama işlemi ile bu dosyayı çekip, dosyanın üzerinde çalışmalarına izin verin. Dosya versiyonlanmamış olduğundan, asla `commit' edilemeyecektir. Ve eğer isterseniz, dosyayı bulunduğu dizinin svn:ignore özelliğine ekleyerek, svn status çıktılarında bu dosyanın başında bir `?' işareti görmekten de kurtulmuş olursunuz.

  24. Herhangi bir arşive svn+ssh ile giriş yaptığımda şifrem ~/.subversion/auth/ içinde saklanmıyor. Her seferinde şifreyi baştan yazmaktan başka bir yol var mı? [Y, A]

    ssh'ın kendine ait parola ve kimlik kontrol önbellek şeması mevcut. Kimlik kontrolü için kullandığı önbellekte saklama işlemi Subversion'ın dışında bir şey olduğu için, Subversion'dan ayrı olarak çözülmelidir.

    OpenSSH ile beraber, anahtar yaratmak için ssh-keygen ve parolaları istemcinin önbelleğine eklemek için ssh-add komutları gelmektedir. keychain ise ssh-agent'ın kullanımını kolaylaştıran bir betik. Windows'da ise, PuTTY popüler bir ssh istemcisi; PuTTYgen ile OpenSSH anahtarlarını almaya ve pageant ile de parolaları önbelleğe atmaya göz atabilirsiniz.

    ssh-agent'ın ayarlanması ise bu belgenin amaçları dışında, ama "ssh-agent"'ın Google araması sizi çabucak ilgili cevaplara ulaştıracaktır. Eğer sabırsız biriyseniz, şu bağlantıları deneyebilirsiniz:

  25. Arşivdeki tüm dosyalar üzerindeki bazı özellikleri nasıl ayarlayabilirim? Ve arşive yeni eklenen tüm dosyaların da bu özelliğe sahip olduğuna nasıl emin olurum? [Y, A]

    Subversion öntanımlı olarak kendiliğinden bir dosyanın içeriğini değiştirmeyecektir; bunun olması için dosyanın svn:eol-style ve svn:keywords özelliklerini kendiniz ayarlamalısınız. Bu Subversion'ı, CVS'in öntanımlı bu özelliğine karşılık daha güvenli kılmasının yanında bazı güçlükler de doğurmaktadır.

    İlk soruya cevap verecek olursak: Bir arşivdeki tüm dosyalar üzerinde belirli bir özelliği sağlamak için bunu zor yoldan yapmalısınız. Yapabileceğiniz tek şey elinizdeki arşiv kopyasındaki tüm dosyalar üzerinde svn propset komutunu çalıştırmak ve ardından svn commit ile bu değişiklikleri onaylatmak. Betikler ile bu işi daha kolay bir hale sokabilirsiniz.

    Ya ilerideki dosyalar için? Ne yazık ki, onaylanan dosyalarda sunucu tarafında bu değişiklikleri yapabilecek otomatik bir mekanizma yok. Bunun anlamı, kullanıcılarınız arşive svn add ile bir dosya eklerken bunun doğru haklarını bilip, ona göre ayarlamaları kendileri yapmalı. Neyse ki, bunu istemci tarafından yapabilecek bir aracımız var. Subversion kitabındaki auto-props kısmını okuyabilirsiniz. Tüm kullancılarınızın dosyalar için auto-props ayarlarını doğru yaptığından emin olmalısınız.

    Sunucuya, onaylanmak istenen dosyaların haklarını kontrol edip ona göre geri çevirilip çevirilmeyeceğine karar veren bir pre-commit askı betiği ekleyebilirsiniz. (Bkz. http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl) Fakat bu yaklaşımın da bazı yan etkileri var. Birisi svn:eol-style özelliğini ayarlamayı unutulursa, örneğin, birisi o dosyayı başka bir OS'da açtığı an anlaşılacaktır. Bir kere fark edildikten sonra da düzeltilmesi kolaydır: Doğru özellikleri ayarla ve dosyayı arşive onayla.

    Not: Bir çok kullanıcının, sunucuların istemcilere auto-props ayarlarını otomatik olarak dağıtması gibi bir isteği oldu. 1974 numaralı özellik isteğinde bu zaten dile getirilmiş ve geliştiriciler tarafından hala üzerinde tartışılmaktadır; fakat şu ana kadar üzerinde başka bir çalışma olmamıştır.

  26. Arşivimin hangi Berkeley DB sürümünü kullandığını nasıl anlayabilirim? [Y, A]

    Eğer sunucunuz kendi makinenizde çalışıyorsa, bunun cevabı basit: sisteminizde hangi BDB sürümü yüklü ise. Eğer arşiv bir yedekten ya da bilinmeyen bir kaynaktan alınmışsa o zaman şöyle bulabilirsiniz:

    En büyük numaralı db/log.* dosyası üstünde 12 ve 16. ofsetlerdeki iki 4 baytlık tam sayıyı gösterecek bir komut çalıştırın. Bunu GNU od ile yapmak için od -j12 -N8 -tx4 log.<number> ya da Mac OS X hexdump ile yapmak için hexdump -s12 -n8 -x log.<number> komutlarını kullanabilirsiniz. İlk tam sayının `magic' numarası, dosyayı bir BDB log dosyası şeklinde tanıtan, 0x00040988 olmalı. İkinci sayı ise log biçiminin versiyonudur; aşağıdaki tablodaki BDB versiyonlarını hangi log biçimi kullanıldığını bulmak için kullanabilirsiniz.

    Log biçim versiyonuBDB program versiyonu
    5 (0x00000005)4.0
    7 (0x00000007)4.1
    8 (0x00000008)4.2
    10 (0x0000000a)4.3
  27. Arşivimde bir internet sayfasının kayıtlarını tutuyorum. Yaptığım her değişiklik onayından sonra asıl internet sayfasının da aynı anda bu güncellemeleri yapmasını nasıl sağlayabilirim? [Y, A]

    Bu sıklıkla karşılaşılan bir sorun olup, çözümü post-commit askı betikleri ile gayet kolaydır. Kitabın 5. bölümü olan askı betiklerine bakabilirsiniz. Yapmanız gereken tek şey çalışan internet sitesini sunucuda bir arşiv kopyası olarak tutmak ve post-commit askısına da karşı sunucuda svn update komutunun çalışmasını sağlayacak bir betik eklemek.

    Pratikte, dikkat etmeniz gereken bir kaç nokta var. Onaylama işlemini sağlayan sunucu (svnserve ya da apache), post-commit askı betiğinin çalıştığı sunucu ile aynı olmalı. Bunun anlamı, program arşiv kopyasını düzgün bir şekilde güncelleyebilmek için doğru haklara sahip olmalı. Diğer bir deyişle, arşiv kopyasının sahibi ve svnserve ya da apache'yi çalıştıran kullanıcının hakları aynı olmalı; ya da en azından kopya arşiv üzerinde doğru haklar olamalı ki sunucu onu güncelleyebilsin.

    Eğer sunucu izninin olmadığı bir arşiv kopyasını (örneğin, joe kullanıcısının ~/public_html/ dizini gibi) güncellemeye çalışacaksa, bir yöntem olarak programı +s izni ile çalıştırmanız olabilir, fakat Unix betiklerin +s ile çalışmasına izin vermez. Bunun yerine ufak bir C programı kullanabilirsiniz:

    #include <stdio.h>
    #include <stdlib.h>
    
    int main(void)
    {
        return \
        ( system("/usr/local/bin/svn update /home/joe/public_html/") != -1 ) \
        ? 0 : 1;
    }
    

    ve derlenmiş programda chmod +s komutunu çalıştırıp, programın `joe' kullancısınına ait olduğuna emin olduktan sonra, post-commit askı dosyasına programı çalıştıracak bir satır eklenebilir.

    Ek olarak apache'nin .svn/ dizinlerini de sunmasını istemeyiz sanırım. Bunun için şu satırı httpd.conf dosyanıza eklemeniz yeterli:

    # Disallow browsing of Subversion working
    # copy administrative dirs.
    <DirectoryMatch "^/.*/\.svn/">
        Order deny,allow
        Deny from all
    </DirectoryMatch>
    
  28. 28. Nasıl arşivdeki tek bir dosyayı çalışma dizinime çekebilirim? [Y, A]

    Subversion tek bir dosyanın `checkout' edilmesini desteklememektedir, sadece bir dizin yapısını `checkout' edebilirsiniz.

    Bunun yerine tek bir dosyayı almak için svn cat komutunu kullanabilirsiniz. Bu dosyanın içeriğini alacaktır, fakat sadece versiyonlanmış bir arşiv kopyası oluşturmayacaktır.

  29. Çalışma dizinimdeki bütün ekleme, silme, kopyalama ve isim değiştirme işlemlerinden, tüm bu işlemler olduktan sonra nasıl haberdar olabilirim? [Y, A]

    Olamazsınız. Denemesi kötü bir fikir.

    Arşiv kopyasının dizaynında basit iki nokta vardır: (1) Dosyaları nasıl isterseniz öyle değiştirin, ve (2) ağaç yapısında herhangi bir değişiklik yapmak istediğinizde (ekleme, silme, yer değiştirme, kopyalama) bir Subversion istemcisi kullanın. Eğer bu kurallara uyulursa, istemci arşiv kopyasını rahatlıkla yönetebilir. Eğer yeniden adlandırmalar ya da diğer işlemler Subversion'ın haberi dışında olursa, kullanıcı arayüzü ihlala edilmiş olup, arşiv kopyanız bozulmuş olabilir. İstemci bu durumda ne olduğuna karar veremez.

    İnsanlar bazen böyle bir problemle karşılaşırlar, çünkü arşivlerinin versiyon kontrolünü saydamlaştırmak isterler. Kullanıcıları kandırarak, onları bir arşiv kopyasına yönlendirirler ve daha sonra bir betik ile bu kopya üzerinde ne değişiklikler yapıldığına bakılıp ona göre ilgili istemci komutu çalıştırırlar. Ne yazık ki, bu yöntem uzun vadede pek işlemez. svn status, betiğin sonradan kolaylıkla svn add ya da svn rm yapabileceği, kayıp ve versiyonlanmamış elemanları gösterir. Fakat bir silme ya da yer değiştirme işlemi gerçekleşirse, şanssızsınız demektir. Betiğiniz bunları algılayabilecek tuhaf metodlara sahip olsa bile, svn mv ya da svn copy işlem olduktan sonra çalışmayacaktır.

    Özet olarak, arşiv kopyaları Subversion altında bir bütündür ve Subversion saydam olmak için tasarlanmamıştır. Eğer istediğiniz saydamlık ise bir apache sunucusu kurarak "SVNAutoversioning" özelliğini kullanabilirsiniz. (Bkz. Subversion kitabında Ek Bölüm C.) Bu sayede kullanıcıların arşive bir ağ diskiymişcesine erişmesini sağlamış olup, yığına yapılan herhangi bir değişikliği otomatik olarak sunucu tarafında onaylatabilirsiniz.

Sorun Giderme

  1. Arşivim sürekli kurtarma işlemine (DB_RUNRECOVERY) ihtiyacı olduğu yönünde hatalar verip donuyor. Bunun sebebi ne olabilir? [Y, A]

    Arşivinizdeki BerkeleyDB veritabanı kesilmelere karşı hassastır. Eğer veritabanına bağlanmış bir uygulama çıkarken düzgün bir şekilde koparmazsa bağlantısını, veritabanı kararsız bir durumda bırakılır. Bunun en sık rastlanan nedenleri:

    Bu çeşit durumların çoğunda svnadmin recover komutuna, arşivi tekrar eski kararlı durumuna getirmek için kullanabilirsiniz. (Daha fazla bilgi.) Şu da unutulmamalı ki, disk alanı sıkıntısı yaşandığı zaman, sık `checkout' ve `update' işlemleri sunan bir arşiv geri dönüşü olmayacak şekilde çökebilir. (Bu yüzden yedek almayı eksik etmeyin.)

    `SegFault' hataları, kasıtlı öldürülen uygulamalar ve disk alanında sıkıntı yaşaması gibi sorunlar ile nadiren karşılaşılır. İzin problemleri ise çok daha seyrek gözlenir: Bir uygulama arşive ulaşır ve yanlışlıkla bir yapının izin ya da sahibini değiştirir; ardından başka bir program aynı yapıya erişmeye çalıştığında tıkanır.

    Bundan kaçınmanın en iyi yolu, arşiv izin ve sahiplerini doğru bir şekilde ayarlamaktır. Önerilere için buraya bakabilirsiniz.

  2. Ne zaman arşive erişmeye çalışsam işlemim hep donup kalıyor. Arşivim zarar mı görmüş? [Y, A]

    Arşiviniz zarar görmüş ya da veriniz kaybolmuş değil. Eğer uygulamanız veritabanına direk (mod_dav_svn, svnlook, svnadmin ya da file:// şeklinde URL kullanarak) erişiyorsa, verilerinize BerkeleyDB kullanarak ulaşıyordur. Berkeley DB kayıt günlüğü tutan bir sistemdir, ki bu da onun herhangi bir işlemde önce onun kaydının tutulduğu anlamına gelir. Eğer uygulamanız bir nedenden dolayı kesilmişse (Control+C ya da `SegFault' ile), arkada bir kilit dosyası (lock file) ve işlemin neden bitirilemediğine dair de bir log dosyası bırakılmıştır. Arşivinize ulaşmaya çalışan herhangi bir uygulama, bu kilit dosyasının ortadan kalkmasını bekleyecektir. Arşivi tekrar ayağa kaldırmak için, Berkeley DB ile yaptığı işlemi bitireceğine ya da bitirmeyip eski kararlı haline geri dönüp dönmeyeceği hakkında seçim yapmanız lazım.

    UYARI: Eğer aynı anda arşivi onarmaya ve bir uygulama ile de ona erişmeye çalışırsanız, verinize ciddi şekilde zarar verebilirsiniz.

    Bunu yapmadan önce arşive erişen tüm yolları kapattığınıza emin olun. (Örneğin, Apache'yi kapatın, svn komutunun çalıştırma izinlerini etkisiz kılın.) Bu komutu, root olarak değil de, arşivin sahibi olarak çalıştırmaya dikkat edin; aksi halde arkanızda root kullancısına ait dosyalar bırakacaksınız ve bunlar da o arşivi yöneten kullanıcı tarafından erişilemez olacaklar. Ayrıca doğru umask değerlerine sahip olduğunuza da dikkat edin; herhangi yanlış bir diğerde arşive erişme iznine sahip grup üyeleri dışarda bırakılacaklardır.

    En basit hali ile onarma işlemini çalıştırmak için:

    $ svnadmin recover /path/to/repos

    Komut bir kez işini bitirdikten sonra db dizinindeki hakları gözden geçiriniz.

  3. Ne zaman bir svn komutu çalıştırsam, çalışma dizininin kilitlendiği şeklinde uyarı veriyor. Arşivim zarar görmüş olabilir mi? [Y, A]

    Arşiv kopyanız kilitlenmedi ya da herhangi bir veri kaybınız olmadı. Subversion'ın arşiv kopyaları kayıt günlüğü tutma özelliği sahip olduklarından, yaptığınız her işlem öncesinde ve sonrasında kaydedilir. Eğer svn istemciniz bir şekilde kesilirse (işlem öldürülür, Control+C kullanılınır ya da işlem `SegFault' verirse), işlemin neden durduğuna dair bilgilerin kayıtları ile birlikte arkada bir kaç kapatılmamış kilit dosyası bırakılır. (svn status komutunda başında L olan dosyalar kilitlenmiş anlamındadır.) Arşiv kopyanıza erişmeye çalışacak olan herhangi bir uygulama bu kilit dosyalarını gördüğünde hata verip çıkacaktır. Arşiv kopyanızı tekrar ayağa kaldırmak için svn istemcinize en son yapmaya çalıştığı işi bitirmesini söylemelisiniz. En basitinden:

    $ svn cleanup working-copy
  4. Yaptığım değişiklikleri onaylatmaya çalıştığımda Subversion kopyamın tarihinin geçmiş olduğu uyarısını veriyor. [Y, A]

    Buna şu üç durum neden olabilir:

    1. Başarısız bir onaylama işlemi ardından biraktığı döküntü ile arşivinizi kirletir.

      Sunucuya yeni bir revizyon eklendiği anda sizin istemcinizin `post-commit' işlemlerini (sizin arşiv kopyanızın da güncellenmesi buna dahil olmak üzere) bitiriyor olması, arşiv ile aranızda bir sorun yaratabilir. Bu bir çok neden olabileceği gibi, (nadiren rastlansa da) veritabanı tarafından ya da (ki en sık bununla karşılaşılınır) yanlış zamanlı ağ kesintilerinden kaynaklanabilir.

      Eğer böyle bir şey olursa, büyük ihtimalle onaylamak istediğini değişiklikler arşivde çoktan onaylanmıştır. svn log -rHEAD komutunu başaramadığınızı zannettiğiniz onaylama işleminizin gerçekleşip gerçekleşmediğini öğrenmek için kullanabilirsiniz. Eğer onaylamayı başarmışsanız, svn revert komutu ile yaptığınız değişiklikleri geri aldıktan sonra svn update ile kopyanızı yeni revizyona yükseltebilirsiniz. (Şuna da dikkat etmek gerek ki, sadece svn update sizin değişikliklerinizin de dahil olduğu güncel sürümü alabilir, svn revert bunu yapmaz.)

    2. Karma revizyonlar.

      Subversion herhangi bir değişikliği onaylarken, istemci sadece revizyon numaralarını ilgilendiren düğümleri onaylar, arşiv kopyasındaki tüm düğümleri değil. Bunun anlamı, bir arşiv kopyasında, son olarak ne onayladığınıza bağlı olarak birbirinden farklı revizyonlara sahip dosya ve dizinler olabilir. Belirli işlemlerde (dizin özelliklerinin değiştirilmesi gibi), eğer arşiv dosyanın daha güncel bir revizyonuna sahip ise veri kaybı olmaması için onaylama kabul edilmeyecektir. (Bkz. Karma Revizyon ile Yapabilecekleriniz.)

      svn update komutunu çalıştırarak arşiv kopyanızı düzeltebilirsiniz.

    3. Gerçekten eski bir revizyonda olabilirsiniz. Şöyle ki, onaylamaya çalıştığınız değişikliğin bulunduğu dosya başka birisi tarafından çoktan yenilenmiştir. Bunun için svn update komutu ile arşiv kopyanızı güncellemelisiniz.

  5. Dağıtımım ile gelen derlenmiş Subversion paketlerini kurdum ve Subversion'ı çalışma dizinime çekmeye çalıştığımda "Unrecognized URL scheme." hatası alıyorum. Bu neden kaynaklı olabilir? [Y, A]

    Subversion arşive ulaşmak için bir eklenti sistemi kullanır. Şu an bu eklentilerden üçü mevcut: ra_local, yerel bir arşive; ra_dav, WebDAV üzerinden bir arşive ve ra_sav de yerel ya da uzaktaki bir svnserve sunucusuna erişmenizi sağlar. Subversion'da herhangi bir arşive erişmeye çalıştığınızda, program verdiğiniz URL şemasına göre uygun eklentiyi dinamik olarak yükler. file:// URL şeması ra_local eklentisini ve http:// URL şeması ra_dav eklentisini yüklemeye çalışacaktır.

    Gördüğünüz hatanın anlamı, dinamik yükleyicinin (ya da bağdaştırıcının) yüklemek istediği ilgili eklentiyi bulamadığıdır. Bu daha çok Subversion'ı kütüphane paylaşımı (shared library) desteği ile kurduğunuzda karşılaşılır. Bu yüzden bir de make install yapmadan önce çalıştırmayı deneyin. Diğer olası bir neden ise, make install dediniz fakat kütüphaneler öyle bir yere yüklendi ki dinamik yükleyici bunları bulamıyor. Linux'da bunu çözmek için paylaşımlı kütüphanelerin bulunduğu dizini /etc/ld.so.conf dosyasına ekleyip ldconfig komutunu vermeniz yeterli. Eğer bunu yapmak istemiyorsanız, ya da bunu yapmak için root haklarınız yoksa, aynı dizini LD_LIBRARY_PATH değişkenine de ekleyebilirsiniz.

  6. Arşivimi aramaya ya da açmaya çalıştığımda hata alıyorum, fakat arşivin URL'sini doğru girdiğimden eminim. Nerede yanlış yapıyor olabilirim? [Y, A]

    Şu soruya bakınız.

  7. `configure', komutunu çalıştırdığımda subs-1.sed line 38: Unterminated `s' command. hatası alıyorum. Sorun neden kaynaklı olabilir? [Y, A]

    Büyük ihtimalle /usr/local/bin/apr-config ve /usr/local/bin/apu-config dosyalarının eski kopyaları sisteminizde mevcuttur. Bunları kaldırın, apr/ ve apr-util/ dizinlerinin tamamen güncel olduğundan emin olduktan sonra tekrar deneyiniz.

  8. Subversion'ı *NIX altında BerkeleyDB 4.2 desteği ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım? [Y, A]

    Subversion, apr-util'e uygun BDB kurulum seçeneklerini sorduktan sonra, BerkeleyDB'yi derler. Bunun anlamı, Subversion ya da Apache ile gelen apr-util'inizin BDB'yi doğru bir şekilde algılayabilmeli. Bunu yapan bir yöntemi apr-util'in ./configure komutuna --with-berkeley-db parametresini vermek. (Bu parametreyi Apache ya da Subversion'a bir kez verdiğinizde, aynıs apr-util için de geçerli oluyor.)

    Problem şundan kaynaklanıyor: BerkeleyDB 4.2, apr-util'in son yayınlanan versiyonundan daha yeni; dolayısıyla apr-util onu nasıl algılayacağını bilmiyor.

    Uzun vadeli çözüm şimdiden hazır: CVS'deki apr-util kolaylıkla BDB 4.2'yi algılayabiliyor. apr-util ya da Apache httpd farklı sürümlere sahip olsa dahi bü özellik geniş ölçüde çalışacak.

    Kısa vadede, elinizdeki sürüm için yapılabilecek en iyi şey apr-util'in ./configure betiğine şu yamayı uygulamak.

    Eğer ilk önce Apache'yi kuruyorsanız, bu yamayı httpd-2.0.48 ile gelen apr-util'in configure betiğine uygulayın ve şu seçenekler ile kurun:

    $ configure \
    > --enable-dav \
    > --enable-so \
    > --with-berkeley-db=/usr/local/BerkeleyDB.4.2 \
    > --with-dbm=db42
    

    Apache'nin doğru BDB kütüphanesi ile kurulup kurulmadığını şöyle anlayabilirsiniz:

    $ ldd /usr/local/apache2/bin/httpd | fgrep libdb-4.2.so

    Ardından Subversion'ı BDB ile daha fazla ilgilenmeye gerek kalmadan kurabilirsiniz. (...fakat Subversion, Apache standart bir yere kurulmamışsa, Apache'nin nereye kurulduğunun ufak bir parametre ile bildirimini isteyebilir.)

    Eğer Apache'yi kurmuyorsanız, yamayı Subversion ile gelen apr-util'in ./configure betiğinine uyguladıktan sonra benzer derleme seçenekleri girerek devam edin:

    $ configure \
    > --with-berkeley-db=/usr/local/BerkeleyDB.4.2 \
    > --with-dbm=db42
    

    Subversion'ın doğru BDB kütüphanesine göre kurulup kurulmadığını yine benzer bir şekilde öğrenebilirsiniz:

    $ ldd /usr/local/bin/svn | fgrep libdb

    Eğer kütüphanelerinizi öntanımlı olandan farklı yerlere kurduysanız, yukarıda izlediğimiz adımlardaki komutların yollarını ona göre ayarlamanız gerekmekte.

  9. Subversion'ı Windows altında MSVC++ 6.0 ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım? [Y, A]

    Büyük olasılıkla sadece en son platform SDK'sını edinmeniz yeterli. VC++ 6.0 ile gelen yeterli derecede güncel değil.

  10. file: URL'sinde bir Windows sürücüsünün harfini nasıl yazabilirim? [Y, A]

    Şu şekilde:

    $ svn import file:///d:/some/path/to/repos/on/d/drive

    Bkz. Arşiv URL'leri

  11. VS.NET/ASP.NET'in ".svn" dizini ile ufak bir uyuşmazlığı var gibi. Bu durumda ne yapabilirim? [Y, A]

    VS.Net, yayınını IIS üzerinde yapmak için WebDAV kullanan, ASP.Net adında bir alt sisteme sahiptir. Bu alt sistem, `.' ile başyana herhangi bir dosya yolunu reddeder. Bu uzaktan bir Subversion arşivi yayınlamaya çalıştığınızda .svn dizininden dolayı sorun oluşturur. Hata mesajı olarak da unable to read project information gibisinden bir şeyler alırsınız.

    Bunun için bir kaç çözüm yolu mevcut:

  12. Ağ üzerinden bir Subversion arşivine yaptığım değişiklikleri onaylatmaya çalışırken sorun yaşıyorum. [Y, A]

    Diyelim ki, kullanıcılardan biri yerel arşivi `import' ederken sorun yaşamadığını bildirmiş olsun:

    $ mkdir test
    $ touch test/testfile
    $ svn import test file:///var/svn/test -m "Initial import"
      Adding         test/testfile
      Transmitting file data .
      Committed revision 1.
    

    Fakat aynı şey uzaktaki bir arşiv söz konusu olduğunda sorun yaşadığını da bildirmiş olsun:

    $ svn import http://svn.sabi.net/test testfile -m "import"
      nicholas's password: xxxxxxx
    
      svn_error: #21110 : <Activity not found>
    
      The specified activity does not exist.
    

    Görüldüğü üzre, httpd işlemi REPOS/dav/ dizini üzerinde yazma haklarına sahip değil. Apache'nin dav/ (ve tabiki db/) dizinine yazma yetkisi olduğundan emin olun.

  13. Windows XP üzerinde çalışan Subversion sunucum bazen zarar görmüş veri yolluyor gibi. Böyle bir şey gerçekten olabilir mi? [Y, A]

    Windows XP Servis Paketi 1'i yüklemelisiniz. Servis paketleri hakkında tüm bilgilere şu adreste ulaşabilirsiniz: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949.

  14. Subversion sunucusu ile istemci arasında geçen haberleşmeyi en iyi şekilde ağdan nasıl dinleyebilirim? [Y, A]

    İletişimi Ethereal programı ile dinleyebilirsiniz:

    1. Capture menüsünden, Startı seçiniz.
    2. Filter kısmına port 80 yazın ve karma özelliğini (`promiscuous mode'u) kapatın.
    3. Subversion istemcinizi çalıştırın.
    4. Stop tuşuna basın (çoğunlukla küçük bir pencerededir). İşte şimdi dinlemiş oldunuz. Birsürü satırdan oluşuyor olması gerek.
    5. Listenin oluştuğu tablonun başındaki Protocol'e tıklayarak, paketleri kullandıkları protokole göre dizin.
    6. Ardından ilk ilgili TCP satırını seçin.
    7. Üzerine sağ tıklayıp, Follow TCP Stream seçeneğini seçin. Subversion istemcisinin HTTP işletişiminde kullandığı istek ve cevapları görüyor olmalısınız.

    Yukarıdaki talimatlar Ethereal'ın grafik arayüz versiyonuna göredir ve (tethereal ile bilinen) komut satırı versiyonunda uygulanmamalıdır.

    Bunun yanısıra, eğer güncel (0.16 sürümünden yüksek) istemciler kullanıyorsanız, sunuculardaki neon-debug-mask seçeneğini ayar dosyalarında etkin hale getirirseniz, svn istemcinizi çalıştırdığınızda hata ayıklama mesajları ekrana döküleceltir. neon-debug-mask değişkeninin numerik değerleri olan NE_DBG_... tanımlarının değerlerine ne_utils.h başlık dosyasından ulaşabilirsiniz. `neon' 0.23.7 için, neon-debug-mask'ı 130 (NE_DBG_HTTP+NE_DBG_HTTPBODY) gibi bir değere ayarlamanız, HTTP iletişimde akan verinin ekrana dökülmesini sağlayacaktır.

    Ağ üzerinde tarama yaparken, sıkıştırma özelliğini de kapamak isteyebilirsiniz. Bunun için config ayar dosyasındaki compression parametresine bakabilirsiniz.

  15. Neden svn revert açık bir hedefe ihtiyaç duyuyor? Neden öntanımlı olarak rekürsif değil? Bu özelliği neredeyse diğer tüm komutlar ile farklılaşıyor. [Y, A]

    Kısaca: Bu sizin iyiliğiniz için.

    Subversion verinizin korunmasına çok öncelikli bir önem verir ve bunu sadece versiyonlanmış veriniz için de yapmaz. Versiyonlanmış ve versiyon kontrol sistemine eklenmek üzere ayarlanmış dosyalar büyük bir dikkatle işlenmelidir.

    svn revert komutu açık bir hedefe ihtiyaç duyar (istenilen hedef dizin o an bulunduğunuz yer olsa bile) - ve bu bunu başarmanın tek yoludur. Bu ihtiyaç (ve eğer istiyorsanız beraberinde --recursive (-R) özelliği) sizin ne yaptığınızdan emin olmanız için kastılı bir şekilde yer almaktadır. Çünkü dosya bir kez geri alındığında (`revert' edildiğinde), yerel değişiklikleriniz tamamiyle ortadan kalkar.

  16. Apache'yi başlattığımda mod_dav_svn db-4.X sürümü yerine db-3.X sürümünü bulduğundan "bad database version" hatası veriyor. [Y, A]

    apr-util kurulumunuz DB-3, svn ise DB-4 ile bağlanmış. Ne yazık ki, DB sembolleri değişik değil. mod_dav_svn modülü Apache'nin işlem alanına alındığında, apr-util'in DB-3 kütüphanesine bağlanmış sembollerine ulaşıyorlar.

    Çözüm, apr-util'in DB-4 desteği ile kurulduğundan emin olmak. Bunun için Apache ya da apr-util'in ./configure betiğine doğru parametreleri (--with-dbm=db4 --with-berkeley-db=/the/db/prefix) vermeniz yeterli.

  17. RedHat 9'da "Function not implemented" hataları aldığımdan Subversion hiçbir şekilde çalışmıyor. Bu sorunu nasıl giderebilirim? [Y, A]

    Bu aslında bir Subversion problemi olmamasına karşın, kullanıcıları sık sık etkiliyor.

    RedHat 9 ve Fedora ile gelen Berkeley DB kütüphaneleri çekirdekteki NPTL (Native Posix Threads Library) desteğini kullanırlar.

    RedHat tarafından dağıtılan çekirdeklerde bu özellik öntanımlı olarak eklenmiş olarak gelir zaten, fakat eğer kendi çekirdeğinizi derlediyseniz bu özelliği etkin kılmamış olabilirsiniz. Böyle bir durumda şuna benzer hata mesajları alabilirsiniz.

    svn: Berkeley DB error
    svn: Berkeley DB error while creating environment for filesystem tester/db:
    Function not implemented
    

    Bunu aşağıdaki bir kaç yöntemden biri ile giderilebilir:

    Ayrıca NPTL desteğine sahip bir Berkeley DB kullanmak için de, NPTL desteğine sahip bir glibc kütüphanesi kullanmanız gerek ki, bu da glibc'nin i686 versiyonu anlamına gelir. (Bkz. http://svn.haxx.se/users/archive-2004-03/0488.shtml)

  18. Neden SVN log dosyasına Apache ile onaylatılan değişikliklerde, değişikliği yapan kullanıcı olarak "(no author)" ibaresi düşülüyor. [Y, A]

    Apache ile `anonymous' (kimliksiz) kullanıcıların arşiv üzerinde yazma haklarına sahip olmasına izin verirseniz, Apache sunucusu, svn istemcisinden kullanıcı adı istemeyecektir; ve hatta, herhangi bir kimlik sorgulaması yapmadan kullanıcıya işlemini yapma izni verecektir. Bu nedenle, Subversion onaylamanın kim tarafından yapıldığından haberdar olamayacağı için, log dosyalarında şöyşe bir ibare yer alacaktır:

    $ svn log
    ------------------------------------------------------------------------
    rev 24:  (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)
    

    Apache'de erişim kısıtlamarının ayarlanması ile ilgili olarak Subversion kitabındaki Bir Arşivin Ağa Bağlanması bölümüne göz atınız.

  19. Arada sırada "Access Denied" hataları alıyorum Windows'ta. Genelde rastgele zaman aralıklarında tekrarlıyor bu hatayı. Neden kaynaklı olabilir? [Y, A]

    Bu daha çok dosya sistemi değişikliklerini kontrol eden Windows servislerinden (anti-virüs yazılımları, indeksleme servisleri, COM+ Durum Bildiri Servisi) kaynaklı bir problem. Sorun Subversion tarafındaki bir hatadan kaynaklı olmadığından, bu da sorunun çözülmesini bizim için güç kılıyor. Konu hakkında yapılan araştırmanın bir son durum özetine buradan ulaşabilirsiniz. 7598. revizyonda bu rastlantının karşıya çıkma sıklığını azaltacak yeni bir metod geliştirildiğinden, eğer 7598'den daha düşük bir revizyona sahipseniz, bunu son sürüme yükseltmeniz tavsiye olunur.

  20. FreeBSD üzerindeyken bazı komutlar (özellikle svnadmin create) zaman zaman donuyor. Neden kaynaklı olabilir? [Y, A]

    Bu genelde sistemde var olan entropi eksikliğinden olur. Büyük olasılıkla sisteminizi hard-disk ve ağ kesmeleri (`interrupt'ları) gibi kaynaklarından entropi kazanacak şekilde ayarlamanız gerekmekte. Özellikle random(4) ve rndcontrol(8) olmak üzere, bu değişikliği etkileyecek komutların kılavuz sayfalarına (`manpage') bakınız.

  21. Arşivimi bir internet tarayıcısı ile sorunsuz görüntüleyebildiğim halde, svn checkout ile arşive erişmeye çalıştığımda "301 Moved Permanently" şeklinde bir hata alıyorum. Sorun neden kaynaklı olabilir? [Y, A]

    Aldığınız hata, httpd.conf dosyanızın yanlış ayarlandığı anlamına geliyor. Bu hata genellikle Subversion'ın sanal konumunun aynı anda birbirinden farklı iki alanda tanımlanmasından doğmaktadır.

    Örneğin, eğer <Location /www/foo> şeklinde belirttiyseniz arşivinizi ve DocumentRoot değişkeniniz de /www dizinine ayarlıysa başınız dertte demektir. /www/foo/bar dizinine herhangi bir istek geldiğinde Apache /foo/bar isimli gerçek bir dosyayı DocumentRoot altında tanımlı /www altında mı, yoksa mod_dav_svn için belirttiğimiz /www/foo için /bar altında mı bulması gerektiğine karar veremiyor. Ve genellikle böyle durumlarda ortaya çıkan "Moved Permanently" (kalıcı olarak kaldırılmıştır) hatasını düşüyor.

    Çözümü için arşiv olarak belirttiğiniz konumun, başka bir tanımlamanın konumu ile kesişmediğine dikkat edin.

  22. Bir dosyanın eski bir sürümüne svn ile bakmaya çalıştığımda "path not found" hatası alıyorum. Bunun sebebi ne olabilir? [Y, A]

    Subversion'ın diğer güzel bir özelliği ise, arşivin kopyalama ve yeniden adlandırma işlemlerini anlayıp, eski bağlantıları koruması. Örneğin, /trunk dizinini /branches/mybranch şeklinde kopyalarsanız, arşiv, `brach'deki herbir dosyanın /trunk'da bir öncelinin (`predecessor') olduğunu bilir. svn log --verbose komutunu çalıştırırsanız kopyalama işleminin geçmiş kayıtlarını listeleyip, yeniden adlandırmayı görebilirsiniz:

    r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line
    Changed paths:
       A /branches/mybranch (from /trunk:7931)
    

    Ne yazık ki, arşiv tüm bu kopyalama ve yeniden adlandırma işlemlerinden haberdar olduğu halde, istemciler değildir. svn diff, svn merge ve svn cat gibi komutlar yeniden adlandırmaları anlayıp, takip etme yetisine sahip oldukları halde, bunu yapamazlar. Bu özellik post-1.0 sürümüne eklenmek üzere programlanmıştır. (Bkz. #1093) Mesela, svn diff ile /branches/mybranch/foo.c dosyasının iki eski sürümünü karşılaştırmak istediğinizde, yeniden adladırmadan dolayı, komut otomatik olarak aslında iki eski /trunk/foo.c sürümünün karşılaştırılması gerektiğini anlamayacaktır. Bunun yerine, `branch' yolunun bir önceki revizyonda yer almadığı şeklinde bir hata alacaksınız.

    Tüm bu çeşit problemler için kendiniz biraz koşturmak zorunda kalacaksınız. Bu nedenle, kendiniz yeniden adlandırmalardan haberdar olup, bunları svn log --verbose ile öğrenip açıkça svn istemcinize belirtmelisiniz. Örneğin,

    $ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c
    svn: Filesystem has no item
    svn: '/branches/mybranch/foo.c' not found in the repository at revision 1000
    

    komutu yerine

    $ svn diff -r1000:2000 http://host/repos/trunk/foo.c
    ...
    

    komutunu vermelisiniz.

  23. HTTP Digest auth neden çalışmıyor olabilir? [Y, A]

    Bu büyük ihtimalle Apache HTTP sunucusunun 2.0.48 ve öncesi sürümleri için geçerli olan, yaması mevcut, bir hatasından kaynaklı. (Bkz. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040) http://subversion.tigris.org/issues/show_bug.cgi?id=1608 adresine de bulgularınızın uyup uymadığını karşılaştırmak için göz atabilirsiniz.

  24. AIX üzerinde xlc ile derlemeye çalıştığımda hata alıyorum. Neden kaynaklı olabilir? [Y, A]

    Ortam değişkeni olan CFLAGS'a -qlanglvl=extended parametresini eklerseniz derleme işlemi xlc için biraz daha esnekleşip, sorunsuz gerçekleşecektir. Ayrıntılar için http://svn.haxx.se/dev/archive-2004-01/0922.shtml adresindeki mesaja ve mesajın ilgili iletilerine bakabilirsiniz.

  25. Arşivden bir dizini (-N parametresi ile) rekürsif olmayacak şekilde çalışma dizinime çektikten sonra, bazı alt dizinlerin görünmesini istiyorum. Fakat svn up subdir ile bunu yapamıyorum. [Y, A]

    Bkz. İleti #695. svn checkout -N komutunun şuanki uyarlamasında bir takım eksikler mevcut. Bu ise eksik dosyaların olduğu arşiv kopyanızda, "tamsızlık" olarak sonuçlanıyor. Subversion geliştiricilerin hiçbiri böyle bir şeye bağımlılık duymasa da, görünürde bir çok CVS kullancısı bu paradigmaya bağımlı. Şu an itibari ile işleyiş yönteminizi değiştirmekten başka bir şansınız yok: Tüm arşivi kopyaladıktan sonra, arşivi istediğiniz dizinler kapsanacak şekilde daraltabilirsiniz.

  26. mod_dav_svn'yi Windows üzerinde Apache ile çalıştırmaya çalıştığımda, mod_dav_svn.so dosyasını doğru yer olan \Apache\modules altına koyduğum halde, Apache'den modülü bulamadığına dair hata alıyorum. [Y, A]

    Bu hata mesajı böyle bir durum için biraz yanıltıcı. Daha çok Apache mod_dav_svn.so tarafından gerek duyulan bir kaç DLL'nin yüklenememesi ile ilgili. Eğer Apache bir servis olarak çalışıyorsa, normal bir kullanıcı ile aynı PATH değişkenine sahip olmayacaktır. libdb4*.dll, libeay32.dll ve ssleay32.dll dosyalarının \Apache\bin ya da \Apache\modules altında olduğundan emin olun. Eğer belirtilen dizinlerin birinde değillerse, bir kopyalarına Subversion'ın kurulum klasörü altından ulaşabilirsiniz.

    Eğer bu probleminizi hala çözmezse, Dependency Walker gibi bir araç kullanarak mod_dav_svn.so'nin çözülmemiş bağımlılıklarını görebilirsiniz.

  27. Neden arşiv askılarım çalışmıyor. Dışarıdan program çağırmaları gerektiği halde hiç de öyle bir çağrı yolluyor gözükmüyorlar. [Y, A]

    Arşiv askılarından program çalıştırmaya çalışırken programların tam yollarını girmeyi deneyiniz. Subversion askıları çalıştırdığında, bulundukları ortam, Subversion'ı başlatan kullanıcının ki ile aynıdır; ki bu, siz aynı programları elle çalıştırmayı denediğinizde kullandığınız ortamdan farklı bir ortam olabilir. Özel olarak: Unix üzerinde $PATH, Windows üzerinde %PATH%, beklediğiniz dizinlere sahip olmuyor olabilir.

  28. Neden --diff-cmd parametresi ile -u parametresini kullandığımda uyarı alıyorum. --extensions parametrei ile bunu etkisiz kılmaya çalıştığım halde olmuyor. [Y, A]

    Dışarıdan bir `diff' programı kullandığınızda, Subversion komut satırını gerçekten karmaşık bir hale sokar. İlk olarak belirtilen --diff-cmd'dir. Ardından --extensions veya --extensions belirtilmezse (ya da '' şeklinde belirtilirse) -u gelir. Üçüncü ve dördüncüde, Subversion bir -L ekledikten sonra, ilk dosyanın adını girer (Örneğin: "project_issues.html (revision 11209)"). Beşinci ve altıncı alanlarda yeniden bir -L ve ikinci dosya adı... Yedinci ve sekizinciler ise birinci ve ikinci dosya isimleri... (Örneğin: ".svn/text-base/project_issues.html.svn-base" ve ".svn/tmp/project_issues.html.tmp".)

    Eğer seçtiğiniz `diff' programı bu parametreleri desteklemiyorsa, ufak bir kaplayıcı betik yazarak, bu paramtereleri göz ardı ettikten sonra asıl `diff' programını çalıştırabilirsiniz.

    Uyarı: Subversion çağrılan `diff' programının işlemesi için gönderdiği dosyaları değiştirmesini beklemez; ve böyle bir durumda çalışma kopyanız içinden çıkılmaz bir hal alabilir.

    Daha fazla bilgi için: İleti #2044

  29. Ana! Subversion istemcim şifrelerimi düz bir metin dosyasında tuttuyor. Yuh! [Y, A]

    Sakin olup, derin bir nefes alın ilk önce. (Canım dur daha karpuz kesecez :P)

    Her şeyden önce, kaydedilmiş şifrelerinizin bulunduğu dizinin (Unix sitemlerde genellikle ~/.subversion/auth/ altındadır) haklarının 700, yani orada sadece sizin okuma hakkınızın olduğuna dikkat ediniz. Diskteki veriyi koruması için işletim sisteminize güvenin.

    Eğer bu sizi gerçekten rahatsız ediyorsa, şifreyi saklama özelliğini tamamen kapatabilirsiniz. Bunun için, svn 1.0 istemcisinde, ayar dosyanıza store-auth-creds = no satırını eklemeniz yeterli. svn 1.1 ve üstü istemcilerde ise daha özel bir alanı işaret eden store-passwords = no satırını kullanabilirsiniz. (Son durumda sunucu sertifikaları halen kaydedilmeye devam edecek yalniz.)

  30. "svn: bdb: call implies an access method which is inconsistent with previous calls" hatası alıyorum. Bunu nasıl düzeltebilirim? [Y, A]

    Berkeley DB 4.1'in arasıra kararsız davrandığı oluyor - 4.0 ve 4.2 sürümleri daha iyi. Bu hata mesajı 4.1'i genelden tek bir neden dolayı oluşan bir hatasının belirtisi.

    Problemin nedeni Subversion BDB-stili arşivi oluşturan tablolardan birinin veritabanı biçim alanında bozulma oluşması. Nedeni bilinmemekle birlikte, `btree' tipinden `recno' tipine geçişi sağlayan tablolardan birini neredeyse her zaman kopyalar. En basitinden kurtarma prosedürü için gerekli adımlar aşağıda anlatılmıştır - eğer bunlar başarılı olmazsa, Subversion Kullancıları E-Posta Listesi ile temasa geçebilirsiniz.

  31. `hotbackup` ile arşivimin yedeğini almaya çalıştığımda, svnadmin 2Gb'den büyük dosyalarda hata veriyor. [Y, A]

    APR'nin Apache 2.0.x ve Subversion 1.x ile kullanılan önceki 0.9 `branch'ındeki versiyonları 2Gb'den büyük dosyaların kopyalanmasına izin vermemekte. svnadmin hotcopy problemini çözen bir düzeltme APR'ye 0.9.5+, Apache'ye de 2.0.50+ sürümlerinde eklendi. Bu düzeltme tüm platformlarda çalışmıyor, fakat Linux'da çalışıyor.

  32. Henüz yeni onayladığım bir dosya için ilgili log kayıtlarını göremiyorum. Neden olabilir? [Y, A]

    Farzedin ki svn checkout ile içinde bir foo.c dosyası bulunan bir arşivin 7. revizyonunu (r7) çalışma kopyanız olarak indirdiniz. Dosya üzerinde değişiklikler yapıp ve bunları onayladınız. Bu noktada iki şey olur:

    Şimdi karma revizyonlu çalışma kopyası denen şeye sahibiz. Sadece bir tek dosya r8'de, fakat diğer bütün dosyalar onaylanana ya da svn update denene kadar r7'de kalır.

    $ svn -v status
       7        7 nesscg       .
       8        8 nesscg       foo.c
    

    Eğer svn log komutunu hiçbir argüman vermeden çalıştırırsanız, komut şuanki dizinin log bilgisini ekrana döker. (Yukarıdaki listede '.' ile geçen.) Şuan bulunduğunuz dizin de hala r7'de olduğu için, r8 için log bilgisini göremezsiniz.

    Son log bilgierini görmek için, şunları yapabilirsiniz:

    1. svn log -rHEAD
    2. svn log URL (URL, arşivin URL'sini gösteriyor.)
    3. Sadece bir dosyanın log bilgisini görmek için: svn log foo.c
    4. Tüm arşivinizi yükseltin ve haliyle tüm dosyalar r8'e geçeceğinden svn log komutunu kullanın.

Geliştirici Soruları

  1. Bellek diski (`ram disk') üzerinde nasıl regresyon testi yapabilirim? [Y, A]

    Bkz. http://svn.haxx.se/dev/archive-2003-02/0068.shtml.

Referanslar

  1. Subversion tarafından kullanılan tüm HTTP metodları neler? [Y, A]

    Aşağıdaki e-posta her şeyi söylemektedir. Yazarın da altını çizdiği gibi, Subversion aslında henüz tüm WebDAV/DeltaV metodlarını kullanmamaktadır, ama muhtemelen günün birinde bu olacak. Bu yüzden eğer bir proxy kuruyorsanız, bunların hepsine izin verebilirsiniz:

    From: Nuutti Kotivuori <naked@iki.fi>
    Subject: Re: list of HTTP messages used by svn?
    To: "Hamilton Link" <helink@sandia.gov>
    Cc: dev@subversion.tigris.org
    Date: Sat, 10 Aug 2002 13:51:52 +0300
    
    Hamilton Link wrote:
    >Önerebileceğiniz svn kullandığı tüm HTTP metodların listesini
    >bulabileceğim bir adres var mı? İlgili dökümantasyondan
    >(project_faq.html ve INSTALL dosyası) bulabildiğim kadarı ile,
    >svn'nin kullandığı metodların listesi en azından şöyle:
    >
    >GET, PROPFIND, REPORT, OPTIONS, MERGE, MKACTIVITY, and CHECKOUT
    >
    >Fakat bunlar benim sadece özel olarak bulduklarım ve hepsinin
    >kullanıldığından da tam olarak emin değilim, ve pek de hakkında
    >fikir yürütme yanlısı değilim.
    >
    >Eğer elimde tam bir liste olsaydı, şirketin proxy'lerine
    >bakan yöneticilere birçok kez yerine bir kere giderdim ve
    >sorunsuz bir çıkış için gerekli değişiklikleri onlara bildirip
    >proxy'de kesintisiz bir svn desteğine sahip olurdum.
    
    http://www.webdav.org/deltav/WWW10/deltav-intro.htm
    
    Listenin bir kopyası burada:
    
    HTTP/1.1: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, CONNECT
    
    WebDAV: LOCK, UNLOCK, PROPFIND, PROPPATCH, COPY, MOVE, MKCOL
    
    DeltaV: CHECKIN, CHECKOUT, UNCHECKOUT, VERSION-CONTROL, REPORT,
    UPDATE, LABEL, MERGE, MKWORKSPACE, BASELINE-CONTROL, MKACTIVITY
    
    Subversion bunların dışında başka bir metod kullanmamaktadır, ne de
    bunların hepsini tam olarak kullanmaktadır. Fakat tüm WebDAV/DeltaV
    desteğine sahip olmak diğer bir kaç rastgele seçimden daha iyi. Eğer
    ayarlara sahip geçerli proxy'niz Squid ise, o büyük ihtimalle HTTP/1.1
    ve WebDAV için gerekli her şeye sahiptir - ve ona sadece DeltaV
    eklentilerini eklemeniz yeterli.
    
    Bu listeyi şirketinizin proxy yöneticisine verebilir ve eğer isterse
    daha fazla bilgi için RFC'leri kontrol edebileceğinin açıklamasını
    yaparsınız.
    
  2. 'bikeshed' de nedir? [Y, A]

    Poul-Henning Kamp'ın freebsd-hackers'a gönderdiği mesaja bakınız: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING.

  3. `baton' tam olarak nedir? [Y, A]

    Subversion'ın kaynak kodu boyunca bir çok noktada `baton'a link vardır. Bunlar fonksiyonlara bağlam sağlayan void * veriyapılarıdır. Diğer API'lerde bu daha çok void *ctx ya da void *userdata şeklinde geçer. Subversion geliştiricileri, etrafta çok fazla dolandıkları için bu tür veriyapılarına `baton' demeyi seçmişlerdir.

  4. Arşiv kesilmiş (`wedged') denerek aslında ne kastediliyor? [Y, A]

    Kesilmiş (`wedged') arşiv:

    Bir Subversion arşivi, çalışma ve depolama olmak üzere, birbirinden farklı
    iki iç bölümden oluşur. Kesilmiş bir arşiv, çalışma bölümü herhangi bir
    nedenden dolayı ulaşılamayan, fakat depo bölümü hala sağlam haldeki arşivdir.
    Bunun için, kesilmiş bir arşivde veri kaybı olmaz. Fakat arşivin ulaşılabilir
    kılınması için çalışma bölümünün düzeltilmesi gereklidir. Detaylı bilgi için
    buraya bakabilirsiniz.
    

    Zarar görmüş (`corrupted') arşiv:

     
    Zarar görmüş bir arşiv ise, bahsedilen depolama bölümünde hasar oluşmuş bir
    arşivdir ve bu nedenle arşivde belli bir veri kaybı gözlenir.
    

    Eric S. Raymond'un "Argo Dosyası"na (`Jargon File') "zarar görmüş"ün (`wedged') bir tanımı için bakabilirsiniz.