- 3.1. Arşivim sürekli kurtarma işlemine (DB_RUNRECOVERY) ihtiyacı olduğu yönünde hatalar verip donuyor. Bunun sebebi ne olabilir?
-
Arşivinizdeki BerkeleyDB veritabanı kesilmelere karşı hassastır. Eğer veritabanına bağlanmış bir uygulama çıkarken düzgün bir şekilde bağlantısını koparmazsa, veritabanı kararsız bir durumda bırakılır. Bunun en sık rastlanan nedenleri:
- Uygulama bir izin sorunu ile karşılaşıp çıkmıştır.
- Uygulama çökmüş ya da `Segmentation Fault' vermiş olabilir.
- Uygulama kasıtlı olarak öldürülmiş olabilir.
- Diskte yer kalmamış olabilir.
Bu çeşit durumların çoğunda
svnadmin recover komutunu, 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 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 sorunları 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 uygulama 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. Öneriler için
buraya bakabilirsiniz.
- 3.2. Ne zaman arşive erişmeye çalışsam işlemim hep donup kalıyor. Arşivim zarar mı görmüş?
-
Arşiviniz zarar görmüş ya da veriniz kaybolmuş değil. Eğer uygulamanız veritabanına doğrudan (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.
 | Uyarı |
|---|
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 kullanıcı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 yerde arşive erişme iznine sahip grup üyeleri dışarda bırakılacaklardır.
En basit hali ile onarma işlemini çalıştırmak için:
$ svnadmin recover /path/to/repos
Komut bir kez işini bitirdikten sonra db dizinindeki hakları gözden geçiriniz.
- 3.3. Ne zaman bir svn komutu çalıştırsam, çalışma dizininin kilitlendiği şeklinde uyarı veriyor. Arşivim zarar görmüş olabilir mi?
-
Arşiv kopyanız kilitlenmedi ya da herhangi bir veri kaybınız olmadı. Subversion'ın arşiv kopyaları günlük kaydı 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 çalışma-kopyası
- 3.4. Yaptığım değişiklikleri onaylatmaya çalıştığımda Subversion kopyamın tarihinin geçmiş olduğu uyarısını veriyor.
-
Buna şu üç durum neden olabilir:
Başarısız bir onaylama işleminin ardında bıraktığı döküntü 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. Buna 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.
- 3.5. Dağıtımım ile gelen derlenmiş Subversion paketlerini kurdum ve Subversion'ı çalışma dizinime çekmeye çalıştığımda "Unrecognized URL scheme." hatası alıyorum. Bu neden kaynaklanabilir?
-
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, uygulama 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.
- 3.6. Arşivimi aramaya ya da açmaya çalıştığımda hata alıyorum, fakat arşivin URL'sini doğru girdiğimden eminim. Nerede yanlış yapıyor olabilirim?
-
- 3.7. configure komutunu çalıştırdığımda subs-1.sed line 38: Unterminated `s' command. hatası alıyorum. Sorun neden kaynaklı olabilir?
-
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.
- 3.8. Subversion'ı *N*X altında BerkeleyDB 4.2 desteği ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım?
-
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 yapmanın bir yolu apr-util'in ./configure komutuna --with-berkeley-db seçeneğini vermek. (Bu seçeneği Apache ya da Subversion'a bir kez verdiğinizde, aynısı apr-util için de geçerli oluyor.)
Sorun şundan kaynaklanıyor: BerkeleyDB 4.2, apr-util'in son yayınlanan sürümünden 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 bu ö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.
- 3.9. Subversion'ı Windows altında MSVC++ 6.0 ile derlemeye çalıştığımda sorun yaşıyorum. Ne yapmalıyım?
-
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.
- 3.10. file:/// URL'sinde bir Windows sürücüsünün harfini nasıl yazabilirim?
-
Şu şekilde:
$ svn import file:///d:/some/path/to/repos/on/d/drive
- 3.11. VS.NET/ASP.NET'in .svn dizini ile ufak bir uyuşmazlığı var gibi. Bu durumda ne yapabilirim?
-
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şlayan 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:
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ı belgelerim var." (Jim Bolla ile bu belgeleri alabilmek için bağlantı kurduk. Eğer alabilirsek onları buraya ekleyeceğiz.) Ya da,
- 3.12. Ağ üzerinden bir Subversion arşivine yaptığım değişiklikleri onaylatmaya çalışırken sorun yaşıyorum.
-
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 tabii ki db/) dizinine yazma yetkisi olduğundan emin olun.
- 3.13. Windows XP üzerinde çalışan Subversion sunucum bazen zarar görmüş veri yolluyor gibi. Böyle bir şey gerçekten olabilir mi?
-
- 3.14. Subversion sunucusu ile istemci arasında geçen haberleşmeyi en iyi şekilde ağdan nasıl dinleyebilirim?
-
İletişimi
Ethereal programı ile dinleyebilirsiniz:
Capture menüsünden, Start'ı seçiniz.
Filter kısmına port 80 yazın ve karma özelliğini (`promiscuous mode'u) kapatın.
Subversion istemcinizi çalıştırın.
Stop tuşuna basın (çoğunlukla küçük bir pencerededir). İşte şimdi dinlemiş oldunuz. Bir sürü satırdan oluşuyor olması gerek.
Listenin oluştuğu tablonun başındaki Protocol'e tıklayarak, paketleri kullandıkları protokole göre dizin.
Ardından ilk ilgili TCP satırını seçin.
Üzerine sağ tıklayıp, Follow TCP Stream seçeneğini seçin. Subversion istemcisinin HTTP işletişiminde kullandığı istek ve cevapları görüyor olmalısınız.
Yukarıdaki talimatlar Ethereal'ın grafik arayüzlü sürümüne göredir ve (tethereal ile bilinen) komut satırı sürümünde 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 iletileri ekrana döküleceltir. neon-debug-mask değişkeninin nümerik 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.
- 3.15. Neden svn revert açık bir hedefe ihtiyaç duyuyor? Neden öntanımlı olarak devirli değil? Bu özelliği neredeyse diğer tüm komutlar ile farklılaşıyor.
-
Kısaca: Bu sizin iyiliğiniz için.
Subversion verinizin korunmasına çok öncelikli bir önem verir ve bunu sadece sürümlenmiş veriniz için de yapmaz. Sürümlenmiş ve sürüm denetim 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) seçeneği sizin ne yaptığınızdan emin olmanız için kasıtlı bir şekilde yer almaktadır. Çünkü dosya bir kez geri alındığında (revert edildiğinde), yerel değişiklikleriniz tamamiyle ortadan kalkar.
- 3.16. Apache'yi başlattığımda mod_dav_svn db-4.X sürümü yerine db-3.X sürümünü bulduğundan "bad database version" hatası veriyor.
-
apr-util kurulumunuz DB-3, svn ise DB-4 ile bağlanmış. Ne yazık ki, DB sembolleri farklı 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 seçenekleri (--with-dbm=db4 --with-berkeley-db=/the/db/prefix) vermeniz yeterli.
- 3.17. RedHat 9'da "Function not implemented" hataları aldığımdan Subversion hiçbir şekilde çalışmıyor. Bu sorunu nasıl giderebilirim?
-
Bu aslında bir Subversion sorunu 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
Bu aşağıdaki bir kaç yöntemden biri ile giderilebilir:
- db4'ü kendi kullandığınız çekirdeğe göre baştan derleyebilirsiniz.
- Bir RedHat 9 çekirdeği kullanabilirsiniz.
- Kullandığınız çekirdeğe NPTL yamaları uygulayabilirsiniz.
- NPTL desteğine sahip güncel bir çekirdek (>= 2.5.x) kullanabilirsiniz.
- Subversion'ı (Apache'yi) başlatmadan önce, 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.)
- 3.18. Neden SVN günlük dosyasına Apache ile onaylatılan değişikliklerde, değişikliği yapan kullanıcı olarak "(no author)" ibaresi düşülüyor.
-
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, günlük dosyalarında şöyle 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.
- 3.19. Arada sırada "Access Denied" hataları alıyorum Windows'ta. Genelde rastgele zaman aralıklarında tekrarlıyor bu hatayı. Neden kaynaklı olabilir?
-
Bu daha çok dosya sistemi değişikliklerini denetleyen Windows servislerinden (anti-virüs yazılımları, indeksleme servisleri, COM+ Durum Bildiri Servisi) kaynaklı bir sorun. 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 yöntem geliştirildiğinden, eğer 7598'den daha düşük bir revizyona sahipseniz, bunu son sürüme yükseltmeniz tavsiye olunur.
- 3.20. FreeBSD üzerindeyken bazı komutlar (özellikle svnadmin create) zaman zaman donuyor. Neden kaynaklı olabilir?
-
Bu genelde sistemde var olan entropi eksikliğinden olur. Büyük olasılıkla sisteminizi sabit disk ve ağ kesmeleri gibi kaynaklarından entropi kazanacak şekilde ayarlamanız gerekmekte. Başta random(4) ve rndcontrol(8) olmak üzere, bu değişikliği etkileyecek komutların kılavuz (man) sayfalarına bakınız.
- 3.21. Arşivimi bir internet tarayıcısı ile sorunsuz görüntüleyebildiğim halde, svn checkout ile arşive erişmeye çalıştığımda "301 Moved Permanently" şeklinde bir hata alıyorum. Sorun neden kaynaklı olabilir?
-
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 arşivinizi <Location /www/foo> şeklinde belirttiyseniz 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.
- 3.22. Bir dosyanın eski bir sürümüne svn ile bakmaya çalıştığımda "path not found" hatası alıyorum. Bunun sebebi ne olabilir?
-
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 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. hata bildirimi) 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.
- 3.23. HTTP Digest auth neden çalışmıyor olabilir?
-
- 3.24. AIX üzerinde xlc ile derlemeye çalıştığımda hata alıyorum. Neden kaynaklı olabilir?
-
Ortam değişkeni olan
CFLAGS'a
-qlanglvl=extended seçeneğini 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 iletiye ve bu ileti ile ilgili iletilere bakabilirsiniz.
- 3.25. Arşivden bir dizini (-N seçeneği ile) devirli olmayacak şekilde çalışma dizinime çektikten sonra, bazı alt dizinlerin görünmesini istiyorum. Fakat svn up subdir ile bunu yapamıyorum.
-
Bkz.
İleti #695.
svn checkout -N komutunun şu anki 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.
- 3.26. mod_dav_svn'yi Windows üzerinde Apache ile çalıştırmaya çalıştığımda, mod_dav_svn.so dosyasını doğru yer olan \Apache\modules altına koyduğum halde, Apache'den modülü bulamadığına dair hata alıyorum.
-
Bu hata iletisi 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 dizini altından ulaşabilirsiniz.
Eğer bu sorununuzu hala çözmezse,
Dependency Walker gibi bir araç kullanarak
mod_dav_svn.so'nun çözülmemiş bağımlılıklarını görebilirsiniz.
- 3.27. Neden arşiv askılarım çalışmıyor. Dışarıdan program çağrıları gerektiği halde hiç de öyle bir çağrı yolluyor gözükmüyorlar.
-
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ınki 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.
- 3.28. --diff-cmd seçeneği ile -u seçeneğini kullandığımda neden uyarı alıyorum? --extensions seçeneği ile bunu etkisiz kılmaya çalıştığım halde olmuyor.
-
Dışarıdan bir diff uygulaması kullandığınızda, Subversion komut satırını gerçekten karmaşık bir hale sokar. İlk olarak belirtilen --diff-cmd'dir. Ardından --extensions (boşsa yoksayılır), --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 uygulaması bu seçenekleri desteklemiyorsa, ufak bir kapsayıcı betik yazarak, bu seçenekleri göz ardı ettikten sonra asıl diff uygulamanızı çalıştırabilirsiniz.
Uyarı: Subversion çağrılan diff uygulaması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.
- 3.29. N'olamaz! Subversion istemcim parolalarımı düz bir metin dosyasında tuttuyor.
-
Sakin olup, derin bir nefes alın ilk önce. (Canım dur daha karpuz kesecez :P)
Her şeyden önce, kaydedilmiş parolalarınızın 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, parola 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 yalnız.)
- 3.30. "svn: bdb: call implies an access method which is inconsistent with previous calls" hatası alıyorum. Bunu nasıl düzeltebilirim?
-
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 genelde tek bir nedenden dolayı oluşan bir hatasının belirtisi.
Sorunun nedeni Subversion BDB-tarzı arşivi oluşturan tablolardan birinin veritabanı biçim alanında bozulma oluşması. Nedeni bilinmemekle birlikte,
btree türünden
recno türüne geçişi sağlayan tablolardan birini neredeyse her zaman kopyalar. En basitinden kurtarma işlemi 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.
- Hiçbir işlemin arşive erişmeye çalışmadığına emin olun.
- Şimdi, bir zip ya da tar dosyasına arşivinizin yedeğini alın.
- Arşivin db alt dizinine geçin.
- rm __db.* log.*
- db_dump -p -r copies > copies.dump
- copies.dump dosyasını bir metin düzenleyici 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 copies
- db_load copies < copies.dump
- svnadmin dump .. > ../../my-recovered.svndump
- Şimdi yeni bir arşiv oluşturun, daha demin oluşturduğumuz arşiv dökümünü (my-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.
- 3.31. hotbackup ile arşivimin yedeğini almaya çalıştığımda, svnadmin 2GB'tan büyük dosyalarda hata veriyor.
-
APR'nin Apache 2.0.x ve Subversion 1.x ile kullanılan önceki 0.9 dalındaki sürümleri 2GB'tan büyük dosyaların kopyalanmasına izin vermemekte. svnadmin hotcopy sorununu çö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.
- 3.32. Henüz yeni onayladığım bir dosya için ilgili günlük kayıtlarını göremiyorum. Neden olabilir?
-
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:
- Sunucudaki arşiv r8'e yükselir.
- Elinizdeki çalışma kopyasında sadece 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 şu anki dizinin günlük bilgisini ekrana döker. (Yukarıdaki listede '.' ile geçen.) Şu an bulunduğunuz dizin de hala r7'de olduğu için, r8 için günlük bilgisini göremezsiniz.
Son günlük bilgierini görmek için, şunları yapabilirsiniz:
svn log -rHEAD
svn log URL (URL, arşivin URL'sini gösteriyor.)
Sadece bir dosyanın günlük bilgisini görmek için: svn log foo.c
Tüm arşivinizi yükseltin ve haliyle tüm dosyalar r8'e geçeceğinden svn log komutunu kullanın.