SVN, versiyon kontrol sistemi olarak yazılım projelerinde oldukça kabul görmüş bir araçtır. Dağıtık olmayan yapısı nedeniyle geliştiricilerin yaptıkları değişiklikleri merkezi bir sunucuya göndermeleri kaçınılmazdır. Ancak SVN ambarlarının (repository) salt okunur yansıları oluşturularak aşağıdaki faydalar sağlanabilir:
- Merkezi sunucunun yoğun iş yükü altında kalmadan salt okunur şekilde çok sayıda kullanıcının kullanımına açılabilir. Böylece, örneğin açık kaynak projelerin kodlarının geniş kitleler tarafından çekilebileceği bir platform oluşturulmuş olur.
- Ana sunucu ağ üzerinde güvenli bir noktaya alınırken yansılar Internet üzerinden erişime açılabilir. Böylece ana sunucu ve üzerindeki ambarda tutulan dosyalar saldırılara karşı güvenceye alınmış olur.
- Ana sunucuda tutulan dosyalar bu yolla yedeklenebilir.
- Ana (kaynak) sunucunun alan adı main-site.x.y.z olsun.
- Yansı (hedef) sunucunun alan adı mirror-site.x.y.z olsun.
[/] svn = r"conf/svnserve.conf" dosyasında da doğrulanmış (authenticated) kullanıcılara en azından okuma hakkı verilmiş olmalıdır:
auth-access = readYansı sunucusunda öncelikle SVN sunucusu kurulur:
apt-get install subversionÖrneğimizde yansının hizmet verme biçimi olarak inetd süper sunucusu tercih edildi. Bunun için aşağıdaki satır /etc/inetd.conf dosyasına eklenir:
svn stream tcp nowait svn /usr/bin/svnserve svnserve -i -r /home/svninetd süper sunucusu yeniden başlatılır:
/etc/init.d/inetutils-inetd restartveya
/etc/init.d/openbsd-inetd restartYansı alınacak ambar oluşturulur:
su - svn svnadmin create mirror-repo cd mirror-repoSenkronizasyon işlemlerini ele alacak betik (hook script) oluşturulur:
touch hooks/pre-revprop-change chmod u+x hooks/pre-revprop-changeAşağıdaki içerik betiğe konulur. Burada, "svn" ana sunucuda salt okunur erişecek şekilde ayarladığımız kullanıcıyı ifade etmektedir.
#!/bin/sh if [ "$3" = "svn" ]; then exit 0; fi echo "Only the - svn - user may edit revision properties through svnsync" >&2 exit 1Ana sunucu ve yansı sunucuları arasında, özellikle de aynı güvenli ağ içinde değillerse, güvenli bağlantı tercih edilmelidir. Bu amaçla yansı sunucusu tarafında gizli ve açık anahtar ikilisi üretilir:
su - svn cd ~/.ssh ssh-keygen -t dsa -b 1024 -f mirror-site.keyBöylece .ssh dizininde "mirror-site.key" adlı gizli anahtar ve buna karşılık gelen "mirror-site.key.pub" adlı açık anahtar dosyası üretilmiş olur. Bu açık anahtar dosyasının içeriği, ana sunucudaki "svn" kullanıcısının ".ssh/authorized_keys" dosyasına eklenir.
Yansı sunucusunda svn kullanıcısı ile linux oturumu açılır:
su - svnSVN_SSH ortam değişkeni aşağıdaki gibi ayarlanır:
export SVN_SSH="ssh -i /home/svn/.ssh/mirror-site.key"Yansı sunucusu aşağıdaki gibi ilklendirilir:
svnsync init file:///home/svn/mirror-repo svn+ssh://svn@main-site.x.y.z/home/svn/main-repoİlk senkronizasyon başlatılır:
svnsync sync file:///home/svn/mirror-repoSenkronizasyon işlemlerini zamanlanmış görev haline getirmek için crontab ayarlaması yapılır:
crontab -eAçılan editör ekranına ağıdaki satır eklenir. Bu örnekte her saat başında senkronizasyon operasyonu başlatılacaktır.
0 * * * * (export SVN_SSH="ssh -i /home/svn/.ssh/mirror-site.key"; svnsync sync file:///home/svn/mirror-repo)Bu otomasyon yansı sunucusunu en fazla bir saat gecikmeyle ana sunucu ile senkron tutacaktır. Yarıda kalan senkronizasyon işlemleri nedeniyle yansı ambarı kilitlenir ve senkronize edilemez hale gelirse aşağıdaki komut yansıyı kilitli durumdan kurtaracaktır:
svn propdel svn:sync-lock --revprop -r 0 file:///home/svn/mirror-repoHepsi bu kadar.

5 yorum:
darcs kullanıdn mı peki Hadi hocam ? http://darcs.net/
Merhaba Murat. Darcs kullanmadım. Dağıtık versiyon kontrol sistemleri sanırım merkezi kontrolün çok gerekmediği ve merkezi bir sunucuya sürekli online erişimin sağlanamadığı geliştirme ortamları için ideal gibi. Şimdilik, aynı anda kullanma durumunda olmadığım farkli bilgisayarlardaki kişisel verilerimi geçmiş bilgisi olacak şekilde senkronize etmek için kullanabilirim gibime geliyor. Bu amaçla mercurial (http://mercurial.selenic.com/) ile ufak denemelerim oldu. Kullanımı kolay. Ancak dediğim gibi ne tür kullanım durumlarında ideal oldukları konusu bende henüz tam olarak olgunlaşmadı. Deneyimlerimi aktaracağım.
Merhaba. Güzel bir yazı olmuş. svn'i yeterince bilmemekle birlikte böyle bir şeye ihtiyacım vardı. Ama aklıma şöyle bir şey geldi. ana depo ve senkronize depolar birbirinden senkronize olabilirler mi? Yani ben hangi depoya commit edersem edeyim diğer depo bundan etkilensin diye bir düşünce. Ben arada senkronize depoyu kullanayım ve ana depo senkronize depodan kendini senkronize etsin desem bu yazdıklarınızla mümkün mü?
Merhaba. Burada ana depo yazılabilir, senkronize depolar salt-okunur olacak şekilde bir senaryoyu anlatmaya çalıştım. Değişikliklerin ana depo üzerinde (tek bir yerden) yapıldığı, ama okumaların senkronize sunucular tarafından yapılabildiği bir yapı söz konusu. Böyle bir yapıda senkron sunucuları, örneğin açık kaynak kodlu projelerin kaynak kodlarına salt-okunur yansılar oluşturup yoğun erişim talebine cevap verme amaçlı kullanabilirsiniz. Salt okunur olarak konfigüre edildikleri için de ana depodaki çalışmanın saldırılardan korunur olması sağlanmış olur. Aynı zamanda mevcut ana deponun periyodik yedeğini alma amacıyla kullanılabilir. SVN deposunun geçmişe dönük yedeklerini ayrı ayrı oluşturmanız gerekmez. Çünkü SVN deposu kendi içinde geçmişe dönük bilgiyi saklar durumdadır.
Sözünü ettiğiniz ihtiyaca yönelik olarak dağıtık versiyon kontrol sistemleri (mercurial ve darcs gibi) önerilebilir. Ancak bildiğim kadarıyla bunlarda da ana deponun kendini otomatik (belirli aralıklarla) senkronize etmesi şu an için söz konusu değil. Sizin ek crontab scriptler'i yazarak çözmeniz gerekir diye tahmin ediyorum.
Bilgi için teşekkür ederim :D
Yorum Gönder