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.
configure, komutunu
çalýþtýrdýðýmda subs-1.sed line 38: Unterminated `s' command.
hatasý alýyorum. Sorun neden kaynaklý olabilir?file: URL'sinde bir
Windows sürücüsünün harfini nasýl yazabilirim?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.svnadmin create) zaman zaman donuyor. Neden kaynaklý
olabilir?
svn checkout ile arþive eriþmeye
çalýþtýðýmda "301 Moved Permanently" þeklinde bir hata alýyorum. Sorun
neden kaynaklý olabilir?svn ile bakmaya çalýþtýðýmda "path not found" hatasý
alýyorum. Bunun sebebi ne olabilir?svn up subdir
ile bunu yapamýyorum.\Apache\modules altýna koyduðum halde, Apache'den modülü
bulamadýðýna dair hata alýyorum.--diff-cmd parametresi ile
-u parametresini kullandýðýmda uyarý alýyorum.
--extensions parametrei ile bunu etkisiz kýlmaya
çalýþtýðým halde olmuyor.svnadmin 2Gb'den büyük dosyalarda
hata veriyor.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.
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.
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.
Ý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.
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.
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.
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.
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.
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/)
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.
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.
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.
Proje durum sayfamýza bakabilirsiniz: http://subversion.tigris.org/project_status.html.
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.
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.
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.
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.
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.
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.
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.
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:
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:
svn cp/mv aslýnda sadece tek bir arþivde çalýþýyor.)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.
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ý.
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.
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.
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.
Ç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.
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.
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.
Ý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?
Ö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.
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:
shell# svnadmin dump /path/to/repository > dumpfile.txt
shell# mv /path/to/repository /path/to/saved-old-repository
shell# svnadmin create /path/to/repository
shell# svnadmin load /path/to/repository < dumpfile.txt
`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.
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.
Ö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.
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.
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."
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.
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.
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.
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:
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.
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 versiyonu | BDB program versiyonu |
|---|---|
| 5 (0x00000005) | 4.0 |
| 7 (0x00000007) | 4.1 |
| 8 (0x00000008) | 4.2 |
| 10 (0x0000000a) | 4.3 |
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>
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.
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.
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.
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.
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
Buna þu üç durum neden olabilir:
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.)
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.
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.
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.
Þu soruya bakýnýz.
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.
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.
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.
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
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:
Burada anlatýldýðý gibi, istemcinizi
.svn yerine baþka bir dizin kullanacak þekilden yeniden
derleyin. Ya da,
Eðer TortoiseSVN kullanýyorsanýz, bu problem için düzeltilmiþ bir istemci kullanabilirsiniz. (Bkz. http://tortoisesvn.tigris.org/download.html. Ve ya,
http://weblogs.asp.net/fbouma/archive/2004/02/28/81479.aspx adresindeki Jim Bolla'nýn tavsiyesini deneyin: "Eðer yerel ya da uzakta paylaþýmdaki bir internet projelerinde çalýþýyorsanýz, projeyi normal bir sýnýf kütüphanesi (regular class library) projesine çevirerek bu sorundan kurtulabilirsiniz. Bunun nasýl yapýlacaðýna dair internetteki kaynaklardan derlediðim bazý dökümanlarým var." (Jim Bolla ile bu dökümanlarý alabilmek için baðlantý kurduk. Eðer alabilirsek onlarý buraya ekleyeceðiz.) Ya da,
.SVN dizin sorununun ardýndan kolaylýkla gelebilirsiniz: http://blog.steeleprice.net/archive/2003/11/09/134.aspx"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.
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.
Ýletiþimi Ethereal programý ile dinleyebilirsiniz:
port 80 yazýn ve karma özelliðini
(`promiscuous mode'u) kapatýn.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.
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.
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.
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:
LD_ASSUME_KERNEL deðiþkeninin 2.2.5
deðerine ayarlý olup olmadýðýný kontrol edip, eðer öyleyse deðiþkeni
kaldýrýn (unset LD_ASSUME_KERNEL). (Bu deðiþken genellikle
RedHat 9 altýndan Wine ve WineX kullanmak için ayarlanýr.)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)
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.
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.
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.
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.
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.
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.
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.
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.
\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.
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.
--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
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.)
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.
db alt dizinine geçin.rm __db.* log.*db_dump -p -r copies > copies.dumpcopies.dump bir editör yardýmý ile açýn. En tepeye yakýn
kýsýmdaki type=recno ibaresini type=btree ile
deðiþtirin ve re_len= ile baþlayan satýrý silin.rm copiesdb_load copies < copies.dumpsvnadmin dump .. > ../../my-recovered.svndumpmy-recovered.svndump) yükleyin ve gerekli aský betikleri ile
ayar dosyalarýný yeni arþive kopyalayýn. Arþivdeki en yüksek revizyon
numarasýnýn olmasý gereken deðer olduðuna emin olun.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.
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:
foo.c r8'e
yükselir, diðer dosyalar r7'de kalýr.Þ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:
svn log -rHEADsvn log URL (URL, arþivin URL'sini gösteriyor.)svn log
foo.csvn log komutunu kullanýn.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.
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.
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.
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.