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.
Volkan YAZICI (a.k.a. `knt')
<v0lkany-at_yahoo-dot_com>
$LastChangedDate: 2005-02-28 04:15:22 +0200 (Mon, 28 Feb 2005) $
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.