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.