- 2.1. Subversion'ın kaynak kodunu nasıl kendi çalışma dizinime çekebilirim (Nasıl `checkout' yapabilirim)?
-
Subversion istemcisini kullanarak aşağıdaki komutu vermeniz yeterli:
$ svn co http://svn.collab.net/repos/svn/trunk subversion
Bu sayede Subversion'ın kaynak kodununun bir kopyasını kendi makinenizdeki subversion dizini altına indirmiş olacaksınız.
- 2.2. Nasıl bir arşiv oluşturup içine veri atabilirim?
-
- 2.3. Önceki bir CVS arşivimi, nasıl bir Subversion arşivine çevirebilirim?
-
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ı okumalısınız.
Eğer cvs2svn.py işinizi görmezse (örneğin arşiviniz üzerinde çevirme işlemi yaparken hata verip çıkıyorsa ya da dal ve etiketlerle 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 tabii ki beraberinde içerdikleri değişik hatalar ile):
- 2.4. Ya eğer bir vekil sunucu arkasındaysam?
-
Eğer Subversion istemcisinde doğru ayarları yapacak olursak, vekil sunucu arkasındayken de rahatlıkla çalışabilirsiniz. İlk önce servers ayar dosyanız üzerinde gerekli değişiklikleri kullanacağınız vekil sunucuya göre yapın. Ayar dosyanın bulunduğu dizin kullandığınız işletim sistemine 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%" komutunu 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 şu anki Subversion tarafından gözardı edilmektedir.
Bir sonraki adımda, vekil sunucunuzun Subversion tarafından kullanılan tüm HTTP yöntemlerini desteklediğine emin olun. Bazı vekil sunucular şu yöntemleri öntanımlı olarak desteklememektedir: PROPFIND, REPORT, MERGE, MKACTIVITY, CHECKOUT. Genel olarak, böyle bir sorunu çözmek ise kullandığınız vekil 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.)
Eğer Subversion trafiğinizi vekil sunucudan geçirmek çok zor ya da imkansızsa ve hala Subversion kodlarını checkout etmek istiyorsanızvekil sunucunun etrafından dolanabilirsiniz. 80. portu filtreleyen bazı vekil 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 farklı olarak şunu da deneyebilirsiniz:
$ svn checkout http://svn.collab.net:81/repos/svn/trunk subversion
ve belki bu sayede vekil sunucuyu atlatmayı başarırsınız. Bir diğer strateji olarak checkout işlemini SSL üzerinden gerçekleştirmek olabilir (ki çoğu vekil sunucu 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.
- 2.5. Sistem yöneticilerim Subversion için bir HTTP sunucu kurmama izin vermiyor? Uzaktan erişim istiyorsam başka bir yolum var mı?
-
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ıyöntemini kullanmak da bununla 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 kullanıcı kimliğ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. Güvenlik duvarınızın 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 güvenlik duvarınızın 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şı hassastı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:
- 2.6. Subversion altında birden fazla projeyi nasıl yönetebilirim?
-
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 her bir 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'in <sussman (at) collab.net> açıklandığı gibi) Bu iki yaklaşım arasındaki fark ise şu şekilde:
İlk durumda projeler arasında kolayca kopyalama ya da yer değiştirme işlemi gerçekleştirirken bunların hepsinin kaydı da saklanmış olur. (svn cp/mv aslında sadece tek bir arşivde çalışıyor.) Revizyon numaraları arşiv genelinde olduğundan, yapılan bir onaylamanın revizyon numarası diğer tüm projeler için de geçerli olacak. Ve bu şöyle bir tuhaflığa yol açacak: Geliştiricilerden birisi projBde bir değişiklik onaylatacak ve bir de bakacak ki bundan önce 10 tane revizyon olmuş, fakat bunları hiçbiri projB üzerinde olmamış. Aslında tam bir anlaşma sayılmaz. Sadece biraz tuhaf geliyor ilk bakışta. Bu daha çok svn'in başına, geliştiriciler sıklıkla rapidsvn üzerinde değişiklik onaylatıp, rapidsvn ile svn aynı arşivde olduğunda geliyor. :-)İkinci seçenek güvenlik açısından daha kolay olabilir: Apache'nin erişim denetimi mekanizmasını kullanarak projeleri birbirleri arasında izole etmek (kullanıcı hak ve dosya izinleri açısından) daha kolay olur. İlk durumda ise projeleri birbirlerinden ayırmak için bayağı becerikli askı (hook) betikleri yazmak zorundayız ("Acaba bu kullanıcı şu dizine yazma hakkına sahip mi?"). Elbette kullanıma hazır böyle bir betiğimiz mevcut.
- 2.7. Birbirinden tamamen farklı iki arşivi nasıl birleştirebilirim?
-
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ğerinin içine atabilirsiniz. Revizyon numaraları kaybolacak, fakat projelerin geçmişi korunmuş olacak.
Peter Davis <peter (at) 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 kendiliğinden 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. İkisi de ayrı URL'de kalmışlardır.
- 2.8. Arşivimi ya da elimdeki çalışma kopyamın yedeğini bir NFS sunucu üstünde tutmalı mıyım?
-
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 iddia 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 tutarsanız bir sorun olmaz.
Çalışan örnekler de 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ı.
- 2.9. Neden arşivim çok yer kaplıyor?
-
Arşiv tüm verinizi bir Berkeley DB ortamı altında
repos/db/ dizininde saklar. Burada bir çok tablo ve günlük dosyası (
log.*) topluluğu bulunmaktadır. Berkeley DB bütün bu tablolarda yapılan değişikliklerin kaydını tutar ve bu sayede herhangi bir kesinti esnasında veri kurtarılabilir. (
Daha fazla bilgi.)
Eğer günlük dosyaları hakkında bir şey yapmazsanız, sürekli değişikliklerin kaydını tutarak, çok fazla disk alanı kaplayacak şekilde büyüyecektir. İstenilen herhangi bir anda Berkeley DB aslında sadece bir kaç günlük dosyasına ihtiyaç duyar (
Şu mesaja ve devamına bakınız); geri kalan rahatlıkla silinebilir. Eğer tüm günlük dosyalarını sonsuza kadar koruyacaksanız, Berkeley DB teorik olarak oluşumunun ilk anından sonsuza kadar tüm değişiklikleri kaydedecektir. Fakat pratikte, eğer yedek alıyorsanız, bu harcadığı disk alanına değmeyecektir.
svnadmin'i kullanarak hangi günlük 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 günlük dosyası silme işlemi etkin haldedir. Bunu kullanmak için svnadmin create komutuna --bdb-log-keep seçeneğini eklemeniz yeterli. Berkeley DB kılavuzundaki DB_LOG_AUTOREMOVE kısmına göz atabilirsiniz.
|
- 2.10. Arşiv izinlerini nasıl doğru bir şekilde ayarlayabilirim?
-
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, tahsis ettiğimiz o özel kullanıcının hakları 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, Subversion kitabının
6. kısmının son bölümüne bakın ve en altta yer alan
checklist kenar çubuğuna dikkat edin. Bu senaryoyu daha güvenli bir hale getirmek için atmanız gereken bir kaç adımın altını çiziyor.
| SELinux / Fedora Core 3+ / RedHat Enterprise kullanıcıları için bilgi: |
|---|
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 şekilde). Örnek vermek gerekirse: Kullanıcılardan biri şu komutu çalıştırabilir:
$ chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY
ki, güvenlik bağlamı arşive ulaşabilecek şekilde ayarlansın.
|
- 2.11. Neden salt-okunur işlemler için de arşive yazma izni gerekiyor?
-
Çoğu istemci işlemi sadece okumadan ibarettir; checkout ya da update gibi. Bir erişim denetimi açısından, 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 zorundadır. 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 "salt-okunur" 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 hareket 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.
- 2.12. Bir dosyayı arşivden nasıl tamamen silebilirim?
-
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 kasıtlı bir şekilde bir verinin asla kaybolmaması için tasarlanmıştır. 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 loadile ile yeni bir arşivin içine atmak. Daha ayrıntılı bilgi için Subversion kitabının
5. bölümüne bakabilirsiniz.
- 2.13. Onaylanan bir değişikliğin günlük kaydını daha sonradan nasıl değiştirebilirim?
-
Günlük kayıtları arşivde her bir revizyona iliştirilmiş özellikler olarak saklanırlar. Öntanımlı olarak, günlük kayıt özelliği (
svn:log) bir kere onaylandıktan sonra değiştirilemez. Bunun nedeni (
svn:log gibi)
revizyon özelliklerinde yapılan değişiklikler, bu özelliğin önceki değerinin tümüyle yok sayılmasına yol açmasıdır ve Subversion bunu yanlışlıkla yapmanızı engellemek için etkisiz kılmıştır. 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, eposta atarak.) Bir kere revizyon özelliklerinin değiştirilmesi etkinleştirildiğinde, bunu
--revprop seçeneğini
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 "yeni gunluk kaydi" URL
Burada N revizyon numarasını, URL ise arşiv adresini belirtiyor. Eğer bu komutu çalıştığı kopyanın içinde giriyorsanız URL kısmını yazmanıza gerek yok.
Bir günlük kaydını değiştirmenin ikinci bir yolu ise svnadmin setlog komutunu kullanmaktır. 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 günlük kaydı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 seçeneğini kullanabilirsiniz. Eğer bu seçeneği kullanacaksanız çok dikkatli olun. Eposta ile haber verme ya da revizyon numaralarının kaydını tutan yedek alma askılarını da atlıyor olabilirsiniz.
- 2.14. Subversion için yazdığım bir yamayı nasıl onaylatabilirim?
-
İlk olarak,
HACKING dosyası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 iletinin içinde ilgili yamanızı içeren bir eposta 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
[ faq.html'de değişklikleri yap ]
$ svn diff faq.html > /tmp/foo
$ Mail -s "[PATCH] FAQ updates" < /tmp/foo
Elbette gönderdiğiniz eposta yamanızın ne yaptığını hakkında uzun ve tatmin edici bir açıklama içerecek,
HACKING belgesinde da yazdığı gibi, ki siz bunu zaten okudunuz, değil mi?
- 2.15. Arşivde belirli bir yere nasıl aktarma (`import') işlemi gerçekleştirebilirim? (Orjinal arşiv kopyasında herhangi bir yer değiştirme ya da silme işlemi yapmadan, sıfırdan bir arşiv kolu oluşturmak gibi.)
-
Ö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 adında bir dizin oluşturduk ve /etc sanki bir normal bir çalışan kopyaymış gibi, 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 doğrudan, çalışan bir arşiv kopyasına otomatik olarak çevrilebilmesi şeklinde de bir istek var.
- 2.16. Bazılarının Subversion sunucularını yükseltirken bahsettikleri "dök/yükle (`dump/load') döngüsü" tam olarak ne anlama geliyor?
-
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şivler 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:
svnserve, Apache ve arşive erişen diğer ne varsa kapatın.
svnadmin'in X sürümünü kullanarak aşağıdaki komutu çalıştırın:
shell# svnadmin dump /path/to/repository > dumpfile.txt
Arşivi başka bir yere taşıyın:
shell# mv /path/to/repository /path/to/saved-old-repository
Şimdi kurulu Subversion'ı X sürümünden, Y sürümüne (derleyerek ya da kurarak) yükseltin.
Subversion'ın yeni kurulu Y sürümü ile aşağıdaki komutu çalıştırın:
shell# svnadmin create /path/to/repository
Yine Y sürümü ile:
shell# svnadmin load /path/to/repository < dumpfile.txt
Tüm askı betiklerini ve diğer şeyleri eski arşivden yenisine kopyalayın.
svnserve, Apache ve diğerlerini baştan başlatın.
| 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 veya load işlemine ihtiyacınız yok demektir.
|
- 2.17. İstemcilerin bir SSPI kimlik denetimi kullanarak Windows `Domain Controller'dan sisteme giriş yapmalarını nasıl sağlayabilirim?
-
Bu belgenin eski bir sürümünde şöyle bir eksik satır var:
Bu satır olmadan, bir tarayıcı kullanıcıdan kimlik bilgilerini isteyecekken, bir Subversion istemcisi bunu yapmayacaktır. (Bir tarayıcı SSPI kimlik denetiminden anlıyor, fakat NEON - Subversion'ın HTTP kütüphanesi - sadece basit kimlik denetimini anlayabiliyor.) İstemci hiçbir zaman kimlik denetimi için sormayacağından, kimlik denetimi isteyen herhangi bir işlem geçersiz olacaktır. Bu satır sayesinde mod_auth_sspi istemci ile basit kimlik denetimi kullanacak, fakat kimlik doğrulaması için Windows `Domain Controller'dan faydalanacak.
- 2.18. .svn dizin isimleri hoşuma gitmedi; SVN tarzı bir şeyi daha çok tercih ederdim. Bunu nasıl değiştirebilirim?
-
Ö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.
- 2.19. Bir dosyanın büyük-küçük harfini nasıl değiştirebilirim?
-
Bu sorun 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ı sorunlu 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ılmış 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.
- 2.20. Katıştırma (`merge') işlemi için CVS'de kullandığım `tag'ları kullanabilir miyim?
-
Aşağıda da gösterildiği gibi, birinin revizyon numarasını hatırlamanıza gerek kalmadan da bir dal, arşiv yığınına katılabilir. 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 dalın, var olan arşiv depomuz olan /home/repos'da nasıl oluşturulacağı anlatılıyor.
Dal katıştırmalarını izlemek için, arşivde tags/branch_traces/ etiketleri saklamak için kuruldu.
# dalları ve etiketleri ayarlayalım
$ 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"
# Dalın çalışan kopyasını checkout edelim
$ svn checkout file:///home/repos/branches/bar_branch wc
$ cd wc
# foo.txt dosyasını düzenleyip arşive teslim edelim
$ echo "some text" >> foo.txt
$ svn commit -m "edited foo"
# trunk'ı değiştirip daldaki değişikleri katıştıralım
$ 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 edelim,
# değişiklikleri içeriyor olmalı.
# katıştırdığımız kısmı teslim edelim
$ svn commit -m "Merge change X from bar_branch."
# Son olarak, son durumu yansıtması için izlemek
# için kullandığımız `trace' dalı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."
- 2.21. Neden $Revision$ anahtar değişkeni değer olarak dosyanın değiştirilmiş son revizyon numarasını alıyor; halbuki ben o anki geçerli sürüm numarasını almasını istiyorum.
-
Subversion arşivin revizyon numarasını genelin tümü 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 uygulamasını indirebilirler. Bunu kullanarak belirtilen bir dosyadaki tüm
$WCREV$ etiketlerini o anki kopyanızın revizyon numarası ile değiştirebilirsiniz.
- 2.22. Subversion da CVS'deki $Log$ gibi bir anahtar değişkene sahip mi?
-
Hayır. CVS'deki $Log$ anahtar kelimesi için bir karşılık yok. Eğer belirli bir dosyanın günlüğüne ulaşmak istiyorsanız, svn log dosyam ya da svn log dosyamın_yolu komutlarını kullanabilirsiniz. Posta listesinden, $Log$'un neden kötü olduğuna dair bir kaç açıklama:
Dallar arasındaki değişikleri birbirine katıştırmaya 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 günlük kayıtları, 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ı günlük kayıtları ile dağıtmak istiyorsanız, kurulu sisteminizin imkanları doğrultusunda bununla uğraşabilirsiniz.
- 2.23. Projemdeki bir dosyanın yerel kullanıcılar tarafından paylaşılabilmesini, ama yapılan değişikliklerin arşive asla geçirilememesini istiyorum. Bu dosya için svn commit'i nasıl etkisiz hale getirebilirim?
-
Dosyayı sürüm denetimi altına koymayın. Bunun yerine sürüm denetimine file.tmpl gibi bir ş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 sürümlenmiş 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.
- 2.24. Herhangi bir arşive svn+ssh ile giriş yaptığımda parolam ~/.subversion/auth/ içinde saklanmıyor. Her seferinde parolayı baştan yazmaktan başka bir yol var mı?
-
ssh'ın kendine ait parola ve kimlik denetleme önbellek şeması mevcut. Kimlik denetimi 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 oluşturmak için ssh-keygen ve parolaları istemcinin önbelleğine eklemek için ssh-add komutları gelmektedir. keychain, ssh-agent'ın kullanımını kolaylaştıran bir betik. Windows'da ise, PuTTY popüler bir ssh istemcisi; OpenSSH anahtarlarını almak için PuTTYgen'e, parolaları önbelleğe atmak için ise pageant'a bakınız.
ssh-agent'ın ayarlanması ise bu belgenin amaçları dışında, ama
ssh-agent'ın Google araması sizi çabucak ilgili yanıtlara ulaştıracaktır. Eğer sabırsız biriyseniz, şu bağlantıları deneyebilirsiniz:
- 2.25. Arşivdeki tüm dosyalar üzerindeki bazı özellikleri nasıl ayarlayabilirim? Ve arşive yeni eklenen tüm dosyaların da bu özelliğe sahip olduğundan nasıl emin olurum?
-
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.
|
- 2.26. Arşivimin hangi Berkeley DB sürümünü kullandığını nasıl anlayabilirim?
-
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. baytlardaki 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.<numara> ya da Mac OS X hexdump ile yapmak için hexdump -s12 -n8 -x log.<numara> komutlarını kullanabilirsiniz. İlk tam sayının sihirli numarası, dosyayı bir BDB günlük dosyasını tanıtan, 0x00040988 olmalı. İkinci sayı ise günlük biçiminin sürümüdür; aşağıdaki tablodaki BDB sürümlerinin hangi günlük biçimini kullanıldığını bulmak için kullanabilirsiniz.
Günlük biçimi sürümü BDB uygulamasının sürümü
5 (0x00000005) 4.0
7 (0x00000007) 4.1
8 (0x00000008) 4.2
10 (0x0000000a) 4.3
- 2.27. Arşivimde bir internet sayfasının kayıtlarını tutuyorum. Yaptığım her değişiklik onayından sonra asıl internet sayfasının da aynı anda bu güncellemeleri yapmasını nasıl sağlayabilirim?
-
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ı, uygulamanın arşiv kopyasını düzgün bir şekilde güncelleyebilmek için doğru haklara sahip olması gerektiği. 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 uygulamayı +s izni ile çalıştırmanız olabilir, fakat Unix betiklerin +s ile çalışmasına izin vermez. Bunun yerine ufak bir C yazılımı 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ş yazılımın üzerinde chmod +s komutunu çalıştırıp, yazılımın joe kullancısınına ait olduğuna emin olduktan sonra, post-commit askı dosyasına yazılımı ç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:
# Subversion çalışma kopyasının yönetsel
# dizinlerinde gezinmeyi yasakla.
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</DirectoryMatch>
- 2.28. Arşivdeki tek bir dosyayı çalışma dizinime nasıl çekebilirim?
-
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, ancak sürümlenmiş bir arşiv kopyası oluşturmayacaktır.
- 2.29. Çalışma dizinimdeki bütün ekleme, silme, kopyalama ve isim değiştirme işlemlerinden, tüm bu işlemler olduktan sonra nasıl haberdar olabilirim?
-
Olamazsınız. Denemesi kötü bir fikir.
Arşiv kopyasının tasarımı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ü ihlal edilmiş olup, arşiv kopyanız bozulmuş olabilir. İstemci bu durumda ne olduğuna karar veremez.
İnsanlar bazen böyle bir sorunla karşılaşırlar, çünkü arşivlerinin sürüm denetimini 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 sürümlenmiş 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 yöntemler içerse 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ş gibi erişmesini sağlamış olup, yığına yapılan herhangi bir değişikliği otomatik olarak sunucu tarafında onaylatabilirsiniz.