svn'de silinen dizini/dosyayı kurtarma

SVN'de tüm işlemlerin kaydı tutulduğu için bir sorun olduğunda geçmişteki kayıtlardan sorunu çözebilirsiniz. En çok karşılaşılan hatalardan biri de yanlışlıkla bir dizini veya dosyayı silmek.

Silenen bir dizin/dosyayı geri getirmek için bir kaç yöntem var.

1. Eski sürmü checkout etme.
Bu en hızlı geri alma yöntemidir. İlgili dosyayı içeren eski bir revizyonu ayrı bir dizini checkout yaparak dosyaları ulaşabilirsiniz. Sonrasında bu silinen dosyaları en güncel revizyonun olduğu dizine taşıyabilirsiniz. Örneğin silinen testdir dizinimiz projemizin 6. revizyonunda oldugunu biliyorsak.
Aşağıdaki komutla bu sürümü checkout edebiliriz.


$ svn co -r 6  http://192.168.1.100/svn/surgate/trunk surgaterev6
A    surgaterev6/test2.txt
A    surgaterev6/test.txt
A    surgaterev6/testdir
A    surgaterev6/testdir/b.txt
A    surgaterev6/testdir/a.txt
Checked out revision 6.

İlgili dizini en güncel sürümün oldugu dizine atalım.

$ cp -pr surgaterev6/testdir surgate-trunk/testdir
$ cd surgate-trunk
$ svn add testdir
$ svn ci

2. Yöntem: Yapılan güncellemeyi geri alma

Yerelde bulunan en güncel proje dizininde iken yapılan işlemi(change) geri alabilirsiniz.
Eğer silme işlemini 8 revizyonda yaptıysanız svn merge ile bu değişikliği geri alabilirsiniz.

$ svn merge http://192.168.1.100/svn/surgate/trunk/   -c -8
--- Reverse-merging r8 into '.':
A    testdir
A    testdir/b.txt
A    testdir/a.txt
--- Recording mergeinfo for reverse merge of r8 into '.':
 U   .
--- Eliding mergeinfo from '.':
 U   .

Not: revizyon numarası verirken 8'in başındaki "-" ye dikkat ediniz.
Bu işlem sonucunda bazı tutarsızlıklar(conflicts) olabilir. bunların elle düzeltilmesi gerekir.

svn diff

svn diff parametresi sayesinde bir dosyanın sizdeki yerel kopyası ile sunucudaki kopyası arasındaki farkları veya iki farklı revizyon numarası arasındaki farkları görebilirsiniz. Komutun çıktısı klasik UNIX diff komutu ile aynıdır.


Örnek bir komut ve çıktısı aşağıdaki gibidir:

# svn diff KERNELCONF |more
Index: KERNELCONF
===================================================================
--- KERNELCONF  (revision 144)
+++ KERNELCONF  (working copy)
@@ -192,48 +192,48 @@
 #device                puc

 # PCI Ethernet NICs.
-#device                de              # DEC/Intel DC21x4x (``Tulip'')
+device         de              # DEC/Intel DC21x4x (``Tulip'')
 device         em              # Intel PRO/1000 Gigabit Ethernet Family
 device         igb             # Intel PRO/1000 PCIE Server Gigabit Family
 device         ixgbe           # Intel PRO/10GbE PCIE Ethernet Family
 #device                le              # AMD Am7900 LANCE and Am79C9xx PCnet
-#device                ti              # Alteon Networks Tigon I/II gigabit Ethernet
-#device                txp             # 3Com 3cR990 (``Typhoon'')
-#device                vx              # 3Com 3c590, 3c595 (``Vortex'')
+device         ti              # Alteon Networks Tigon I/II gigabit Ethernet
+device         txp             # 3Com 3cR990 (``Typhoon'')
+device         vx              # 3Com 3c590, 3c595 (``Vortex'')



Yukarıda görüldüğü gibi +++ ile ifade edilen kısımlar sizdeki çalışan kopya(working copy) ---- ile gösterilen ise svn'deki 144 nolu revizyona ait kayıtları gösterir.


Herhangi bir revizyon numarası ile çalışan kopya arasındaki farklı görmek için -r revizyon numarası parametresi eklenir.


# svn diff -r 110 KERNELCONF 
Index: KERNELCONF
===================================================================
--- KERNELCONF  (revision 110)
+++ KERNELCONF  (working copy)
@@ -192,48 +192,48 @@
 #device                puc

 # PCI Ethernet NICs.
-#device                de              # DEC/Intel DC21x4x (``Tulip'')
+device         de              # DEC/Intel DC21x4x (``Tulip'')
 device         em              # Intel PRO/1000 Gigabit Ethernet Family
 device         igb             # Intel PRO/1000 PCIE Server Gigabit Family

subversion(svn) 1.6 sürümünden 1.7 sürümüne güncelleme

Burada Centos 6.X üzerinde subversion 1.6'dan 1.7 ye geçiş anlatılacaktır. Subversion sunucu tarafında 1.7 sürümü  ile 1.6 sürümü aynı repo formatını kullandığı için sadece subversion paketlerinin güncellenmesi yeterli olacaktır.

Fakat istemci tarafında yeni format kullanıldığı için istemci tarafındaki 1.6 sürümüne ait projenin 1.7 sürümüne güncellenmesi gerekir. Veya en güncel kodlar svn sunucusunda ise istemcideki mevcut 1.6 dizini silinip sunucudan sıfır bir svn checkout yapılması gerekir.



Öncelikle mevcut kurulu subversion versiyonunu bulmak için svn sunucusunda aşağıdaki komutlardan herhangi birini kullanabilirsiniz.

Mevcut sürümü öğrenme:


# rpm -qa |grep subver
subversion-1.6.11-7.el6.x86_64

# svn --version
svn, version 1.6.11 (r934486)
   compiled Jun 23 2012, 00:44:03


Subversion yazılımı ile subversion'daki bir projenin sürüm formatı aynı olmayabilir. Proje eski  sürüm subversion ile oluşturulmuş olabilir. svn'deki projemizin hangi subversion sürümü formatında olduğunu bulmak için projenin altındaki db/format dosyasına bakabilirsiniz.

Daha önceki dökümanımda örnek svn projeleri oluşturmuştum. Örnek surgate projesi için format dosyasına aşağıdaki değerler bulunmaktadır.

 # cat /var/svn/surgate/db/format
4
layout sharded 1000

Yukarıdaki birinci satırdaki sayı değeri bize projenin hangi subversion sürümü ile oluşturulduğunu  veya hangi sürüme kadar desteklendiğini gösterir.
Format numaraları ve farkları:

  Format 1: Subversion 1.1+ tarafından tanınıyor.
  Format 2: Subversion 1.4+ tarafından tanınıyor.
  Format 3:  Subversion 1.5+ tarafından tanınıyor.
  Format 4: Subversion 1.6+ tarafından tanınıyor.
  Format 5: Subversion 1.7-dev ve sonrası tarafından tanınıyor.
  Format 6: Subversion 1.8 tarafından tanınıyor.


Kurulu SVN paketlerinin listesi öğrenilmelidir. Bunun için aşağıdaki komut verilebilir.

# rpm -qa |egrep 'svn-|subversion-'
subversion-1.6.11-7.el6.x86_64
mod_dav_svn-1.6.11-7.el6.x86_64

Güncelleme yapmadan önce Apache servisini kapatmamız gerekir. Bu sayede güncelleme sırasında bir bağlantı isteğinin gelmeyeceğinden emin oluruz.

# /etc/init.d/httpd stop

Şu andaki en güncel sürüm 1.7.8. Aşağıdaki komutlarla yeni RPM paketleri çekilebilir.


# wget http://opensource.wandisco.com/rhel/6/svn-1.7/RPMS/x86_64/mod_dav_svn-
1.7.8-1.x86_64.rpm
# wget http://opensource.wandisco.com/rhel/6/svn-1.7/RPMS/x86_64/subversion-1.7.8-1.x86_64.rpm

Not: Yukarıdaki paketler 64 bit paketleridir. 32 bit işletim sistemi kullanıyorsanız yukarıdaki siteden 32 bit sürümlerini çekmeniz gerekir.

Paketler aşağıdaki komutla güncellenir.

# rpm -Uvh mod_dav_svn-1.7.8-1.x86_64.rpm subversion-1.7.8-1.x86_64.rpm
warning: mod_dav_svn-1.7.8-1.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 3bbf077a: NOKEY
Preparing...                ########################################### [100%]
   1:subversion             ########################################### [ 50%]
1q       2:mod_dav_svn            warning: /etc/httpd/conf.d/subversion.conf created as /etc/httpd/conf.d/subversion.conf.rpmnew ########################################### [100%]


Yeni paketin sürüm numarası kontrol edilir.

# svn --version
svn, version 1.7.8 (r1419691)
   compiled Dec 11 2012, 17:01:48

Herşey normal gözüküyor. Şimdi SVN erişimi için web sunucusunu tekrar açalım.

 # /etc/init.d/httpd start
 


Sunucu tarafındaki işlemler tamamlandı. İstemci tarafında ise svn çalışma dizinimize gidip aşağıdaki komutu verelim.
# cd /home/ismail/projects/surgate
# svn info
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/home/ismail/projects/surgate' is too old (format 10, created by Subversion 1.6)

Gördüğünüz gibi işlemci tarafındaki veritaba formatımız eskide kaldı. Çıktıda belirtildiği gibi proje dizininde iken svn upgrade komutu vererek bu sorunu çözebiliriz.


# svn upgrade
Upgraded '.'

 Not: svn upgrade komutu sunucu tarafında kesinlikle bir operasyon yapmamaktadır. Sadece istemcideki yerel dizinin svn formatını güncellemektedir.

Diğer bir çözüm ise proje dizinini tamamen silin(tabii en güncel kodların svn sunucuda olduğundan emin olun.


 # cd /home/ismail/projects/surgate
# rm -fr surgate
# svn checkout https://192.168.1.10/svn/surgate/trunk surgate 

SVN dahili dizin yapısı

Bir SVN projesinde aşağıdaki dizin ve dosyalar bulunmaktadır.

# ls -al /var/svn/surgate
total 36
drwxr-xr-x 7 apache apache 4096 Feb 12 01:22 .
drwxr-xr-x 5 apache apache 4096 Feb 13 05:57 ..
drwxr-xr-x 2 apache apache 4096 Feb 12 00:47 conf
drwxr-xr-x 3 apache apache 4096 Feb 12 01:22 dav
drwxr-sr-x 7 apache apache 4096 Feb 14 23:32 db
-r--r--r-- 1 apache apache    2 Feb 12 00:47 format
drwxr-xr-x 2 apache apache 4096 Feb 12 00:47 hooks
drwxr-xr-x 2 apache apache 4096 Feb 12 00:47 locks
-rw-r--r-- 1 apache apache  229 Feb 12 00:47 README.txt

Buradaki en önemli dizinler db,hooks ve conf dizinidir. db dizinin hiyerarşisi aşağıdaki gibidir:


db dizini

  db/revs:             revizyonları içerir. Buradaki alt dizindeki her bir dosya bir commit işlemini içerir.

Örnek bir dizi yapısı aşağıdaki gibidir.

# ls  -al /var/svn/surgate/db/revs/
total 12
drwxr-sr-x 3 apache apache 4096 Feb 12 00:47 .
drwxr-sr-x 7 apache apache 4096 Feb 14 23:32 ..
drwxr-sr-x 2 apache apache 4096 Feb 12 01:28 0
# ls  -al /var/svn/surgate/db/revs/0
total 28
drwxr-sr-x 2 apache apache 4096 Feb 12 01:28 .
drwxr-sr-x 3 apache apache 4096 Feb 12 00:47 ..
-rw-r--r-- 1 apache apache  115 Feb 12 00:47 0
-rw-r--r-- 1 apache apache  281 Feb 12 01:22 1
-rw-r--r-- 1 apache apache  321 Feb 12 01:27 2
-rw-r--r-- 1 apache apache  342 Feb 12 01:28 3
-rw-r--r-- 1 apache apache  664 Feb 12 01:28 4

Buradaki en son sayı 4. Bu da en güncel revision numarasının 4 olduğu anlamına gelir. Bunuda svn info komutu ile görebilirsiniz.


# svn info
Path: .
URL: http://192.168.1.100/svn/surgate/trunk
Repository Root: http://192.168.1.100/svn/surgate
Repository UUID: eeb80374-687f-47f5-a93c-3ad0b907a178
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: ismail
Last Changed Rev: 4
Last Changed Date: 2013-02-12 01:28:43 +0200 (Tue, 12 Feb 2013)


db/current

# cat /var/svn/surgate/db/format
4
layout sharded 1000

Yukarıdaki birinci satırdaki sayı değeri bize projenin hangi subversion sürümü ile oluşturulduğunu  veya hangi sürüme kadar desteklendiğini gösterir.
Format numaraları ve farkları:

  Format 1: Subversion 1.1+ tarafından tanınıyor.
  Format 2: Subversion 1.4+ tarafından tanınıyor.
  Format 3:  Subversion 1.5+ tarafından tanınıyor.
  Format 4: Subversion 1.6+ tarafından tanınıyor.
  Format 5: Subversion 1.7-dev ve sonrası tarafından tanınıyor.
  Format 6: Subversion 1.8 tarafından tanınıyor.

db/uuid: Dosyanın UUID(universally unique identifier) değerini gösterir.

Bu değer diğer doğrulama formlarının(URL kontrolu vs) yeterli olmadığı zaman depo kimliğini doğrulamak için Subversion istemcileri tarafından kullanılır.

# cat /var/svn/surgate/db/uuid
eeb80374-687f-47f5-a93c-3ad0b907a178

Bu değer svn info çıktısındaki Repository UUID değerine karşılık gelir.

Repository UUID: eeb80374-687f-47f5-a93c-3ad0b907a178


db/current
En güncel svn revizyon numarasını belirtir.

# cat /var/svn/surgate/db/current
4

svn info çıktısındaki Revision değerine karşılık düşer.


db/fs-type

SVN dosya sistemi formatını belirtir. Default olarak fsfs'dir. Bunun dışında bdb formatı da kullanılabilr.

# cat /var/svn/surgate/db/fs-type
fsfs

db/revprops: revision properties ifadesinin kısaltılmasıdır. Her bir commit işlemindeki güncelleme işlemine ait bilgiler tutar. Örnek bir kayıt aşağıdaki gibidir:

# ls  /var/svn/surgate/db/revprops/0
0  1  2  3  4  5
# cat /var/svn/surgate/db/revprops/0/5
K 10
svn:author
V 6
ismail
K 8
svn:date
V 27
2013-02-21T18:24:37.346410Z
K 7
svn:log
V 20
ikinci test dosyasi

END


hooks dizini

Her bir commit öncesi veya sonrası alınacak aksiyonları belirleyen dosyaları içerir. Ön tanımlı içeriği aşağıdaki gibidir.

# ls -al /var/svn/surgate/hooks/
total 44
drwxr-xr-x 2 apache apache 4096 Feb 12 00:47 .
drwxr-xr-x 7 apache apache 4096 Feb 12 01:22 ..
-rw-r--r-- 1 apache apache 1977 Feb 12 00:47 post-commit.tmpl
-rw-r--r-- 1 apache apache 1638 Feb 12 00:47 post-lock.tmpl
-rw-r--r-- 1 apache apache 2289 Feb 12 00:47 post-revprop-change.tmpl
-rw-r--r-- 1 apache apache 1567 Feb 12 00:47 post-unlock.tmpl
-rw-r--r-- 1 apache apache 3426 Feb 12 00:47 pre-commit.tmpl
-rw-r--r-- 1 apache apache 2410 Feb 12 00:47 pre-lock.tmpl
-rw-r--r-- 1 apache apache 2786 Feb 12 00:47 pre-revprop-change.tmpl
-rw-r--r-- 1 apache apache 2100 Feb 12 00:47 pre-unlock.tmpl
-rw-r--r-- 1 apache apache 2780 Feb 12 00:47 start-commit.tmpl

Yukarıdaki dosyalar  birer template (.tmpl) dosyasıdır. Dosyaların aktif olması için .tmpl uzantısı olmadan dosya oluşturulması gerekir. Örneğin post-commit operasyonu(commit sonrası yaplacak işler) uygulamak için dosya adı post-commit olmalı ve dosya çalıştırılabilir haklara(755) sahip olmalıdır.

post-commit ile genelde şu işler yapılır.

• Her commit sonrası ilgili kişilere e-posta gönderimi
• Commit sonrasında mantis hata takip sistemine kayıt girilmesi

pre-commit ise commit svn'e kabul edilmeden önce yapılacak kontroller için kullanılır. Biz bu özelliği svn commit yapan kişilerin commit mesajında JIRA'daki bir iş numarası girmediğinde commit işleminin reddedilmesi için kullandık. Bununla ilgili yazıyı buradan okuyabilirsiniz.

Yukarıdaki diğer dosyalardaki post ve pre ile benzer şekilde işlemin öncesinde ve sonrasında belli aksiyonlar alınabiliyor. En çok kullanılan dosyalar ise yukarıda bahsettiğim pre-commit ve post-commit dosyasıdır.

conf dizini

Bu dizinde ön tanımlı olarak 3 adet dosya bulunur.
 # ls /var/svn/surgate/conf/
authz  passwd  svnserve.conf

Buradaki authz ve passwd dosyaları yetkilendirme ve kullanıcı parolası tanımlamak için kullanılır. Fakat birden fazla svn projeniz varsa bu dizini kullanmak yerine daha önceki subversion kurulum yazımda bahsettiğim gibi global bir yapılandırma dosyası kullanmak daha sağlıklı olacaktır. Aksi halde her proje dizininde ayrı ayrı authz ve passwd dosyaları tanımlamanız gerekecek.

svnserve.conf dosyası ise svnserve servisinin yapılandırma dosyasıdır. Eğer Apache üzerinden svn yetkilendirmesi yapıyorsunuz bu dosyanın bir anlamı yoktur.




http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure adresinden dizin yapısı hakkında detaylı bilgi alabilirsiniz.

WebSVN Kurulumu

Bir önceki yazdımda svn sunucu kurulumunu anlatmıştım. Bu yazıda svn'in vazgeçilmez bileşeni olan websvn'in kurulumunu Redhat/CentOS Linux'e göre kısaca anlatacağım.

WebSVN adından anlaşılacağı gibi SVN depolarının web arayüzünden görülebilmesini sağlayan bir araçtır. Ne gibi özellikleri vardır?

• İzin verilen tüm depoları görebilirsiniz.
• revision ve commit mesajlarını görebilirsiniz.
• Bir dosyanın daha önceki sürümleri ile arasındaki farkları görebilirsiniz.
• Blame özellliği ile hangi satırları kimlerin değiştirdiğini görebilirsiniz.
• Dosya ve dizinleri indirebilirsiniz.

Kurulum:

www.websvn.info adresinden en güncel sürüm indirilir. An itibari ile 2.3.3 sürümü mevcut.
websvn'in web sunucu üzerinden erişilebilir bir dizine kurulması gerekir. Burada örnek olarak /var/www/html/websvn altına kurulucaktır.

# wget http://websvn.tigris.org/files/documents/1380/49056/websvn-2.3.3.tar.gz
# tar zxvf websvn-2.3.3.tar.gz 
# mv websvn-2.3.3 /var/www/html/websvn
# cd  /var/www/html/websvn/include
# cp distconfig.php config.php
# chown -R apache  /var/www/html/websvn
# chmod 700  /var/www/html/websvn/cache

Bu dosyaya aşağıdaki satırlar eklenir:

 $config->parentPath('/var/svn');
$config->useAuthenticationFile('/var/svn/svnauth.conf'); // Global access file


Yukarıdaki 1. satır ile svn'in ana dizini belirtiler. 2. satır ile de websvn'e erişim yapıldığında kullanıcın sadece erişim hakkı olan projeleri görmesi için kullanacağı svn yetkilendirme dosyasının yolu belirtilir.

Eğer 2. satırdaki useAuthenticationFile parametresini tanımlamazsanız herkes projeleri görebilecektir.

Son olarakda apache ayarları için /etc/httpd/conf.d/subversion.conf dosyasına aşağıdaki satırlar eklenir.

<Location /websvn/>
        AuthType Basic
        AuthName "surgatelabs websvn realm"
        AuthUserFile /var/svn/svnpasswd
        Require valid-user
        SVNParentPath /var/svn/
</Location>


Apache servisi  yeniden başlatıldığında artık websvn'imiz kullanıma hazırdır.

# /etc/init.d/httpd restart


http://sunucuad/websvn adresinden WebSVN'e erişebilirsiniz. Erişmeye çalıştığınızda kullanıcı adı ve parola soran bir popup gelecektir. Buraya SVN'deki kullanıcı adı ve parolanızı yazdığınızda aşağıdaki gibi biir ekran sizi karşılayacaktır. Sonrasında aşağıdaki gibi ekranları görebilirsiniz.

Apache üzerinden SVN erişimi ve yetkilendirmesi

Bu yazıda  RedHat / Centos 6.x Apache üzerinden mod_authz_svn ve mod_dav modüllerini kullanarak svn proje yönetimini anlatacağım.


 # yum install mod_dav_svn subversion httpd

mod_dav_svn paketi ile aşağıdaki dosyalar gelmektedir.

# rpm -ql mod_dav_svn
/etc/httpd/conf.d/subversion.conf
/usr/lib64/httpd/modules/mod_authz_svn.so
/usr/lib64/httpd/modules/mod_dav_svn.so

Öncelikle ana svn dizini olarak bir yer seçilmelidir. Burada tercih tamamen size kalmıştır. Burada örnek olarak /var/svn dizini kullanılacaktır.


Apache ayarlarına geçmeden önce bu dizini oluşturup surgate isimli örnek bir proje açalım.

# mkdir -p /var/svn
# svnadmin create /var/svn/surgate
# chown -R apache.apache  /var/svn
# ls -al /var/svn/surgate/
total 32
drwxr-xr-x 6 apache apache 4096 Feb 12 00:37 .
drwxr-xr-x 3 apache apache 4096 Feb 12 00:37 ..
drwxr-xr-x 2 apache apache 4096 Feb 12 00:37 conf
drwxr-sr-x 6 apache apache 4096 Feb 12 00:37 db
-r--r--r-- 1 apache apache    2 Feb 12 00:37 format
drwxr-xr-x 2 apache apache 4096 Feb 12 00:37 hooks
drwxr-xr-x 2 apache apache 4096 Feb 12 00:37 locks
-rw-r--r-- 1 apache apache  229 Feb 12 00:37 README.txt
İkinci bir proje daha açalım.

# svnadmin create /var/svn/surgategui
 # chown -R apache.apache  /var/svn/surgategui

Sonrasında /etc/httpd/conf.d/subversion.conf dosyası düzenlenir. Dosyada sadece aşağıdaki iki satır aktif durumdadır.

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

Bu satırların altına oluşturulacak her bir proje için aşağıdaki gibi kayıtlar eklenmelidir. Şimdilik sadece tsetproject isimli projemiz olduğu için aşağıdaki gibi kayıt girilir.


Location /svn/surgate>
        DAV svn
        SVNPath /var/svn/surgate
        AuthType Basic
        AuthName "surgatelabs svn surgate project realm"
        AuthUserFile /var/svn/svnpasswd
        Require valid-user
        AuthzSVNAccessFile /var/svn/svnauth.conf
</Location>


Location /svn/surgategui>
        DAV svn
        SVNPath /var/svn/surgategui
        AuthType Basic
        AuthName "surgatelabs svn surgategui project realm"
        AuthUserFile /var/svn/svnpasswd
        Require valid-user
        AuthzSVNAccessFile /var/svn/svnauth.conf
</Location>


Bu ayarları kaydedip apache servisini yeniden başlattığınızda web sunucu tarafında işlemler tamamlanmış oluyor.

# /etc/init.d/httpd restart

Sonrasında web tarayıcınızda http://sunucuIP/svn/surgate yazdığında karşınıza aşağıdaki gibi
parola soran bir ekran gelecektir.

Bundan sonraki süreçte projeye erişecek kulanıcıları tanımlama ve kullanıcılara yetkileri verme işlemi yapılacak.


subversion.conf dosyasında tanımlanan   AuthUserFile /var/svn/svnpasswd parametre ile kullanıcı adı ve parolanın /var/svn/svnpasswd dizininde tutulacağı kabul ediliyor. Bu dosyanın yolunu siz istediğiniz şekilde değiştirebilirsiniz. apache ile birlkte gelen htpasswd komutu ile dosyayı oluşturup ilk kullanıcıyı tanımlayabiliriz

# htpasswd -c -m  /var/svn/svnpasswd ismail
New password:
Re-type new password:
Adding password for user ismail

Buradaki -c ile dosyayı oluşturulur, -m ile de md5 parola kullanılacağı belirtilir. Dosyanın içeriği aşağıdaki gibidir.

 # cat  /var/svn/svnpasswd
ismail:$apr1$b7j98L3C$nTsiexkt.WGEaB2.PqeOv0


Bundan sonra yeni kullanıcı eklenecekse -c parametresi kullanılmamalıdır.
# htpasswd  -m  /var/svn/svnpasswd yusuf
# cat  /var/svn/svnpasswd
ismail:$apr1$b7j98L3C$nTsiexkt.WGEaB2.PqeOv0
yusuf:$apr1$H3Opz/q9$wr8JrJNBGDVRKYvLAdoWJ0

Son olarak  AuthzSVNAccessFile /var/svn/svnauth.conf parametresi ile belirtilen SVN yetkilendirme dosyası tanımlanmalıdır.

# vi /var/svn/svnauth.conf 

[groups]
yoneticiler =  ismail,murat
testgrubu = salih,selcuk
arayuzekibi = erman,emin
[/]
@yoneticiler = rw
@testgrubu = r

[surgate:/]
hasan = rw
mustfa = r


[surgategui:/]
@arayuzekibi = rwilhami = r

Yukaridaki tanımlara göre iki kullanıcı grubu oluşturduk. yöneticiler ve testgrubu.
Bu iki gruptan yönetici grubu tüm projelere rw(okuma,yazma) hakları ile erişiyorken, testgrubu sadece okuma olarak erişmektedir. Bu iki grupta alttaki surgate ve surgategui projelerine erişim hakkı vardır. Ek bir tanım yapmaya gerek yok bunlar için.

surgate projesine hasan okuma yazma hakkı ile erişiyorken, mustafa sadece okuma hakkına sahip.

surgategui projesinde ise arayuzgrubundaki kullanıcılar(erman,emin) okuma yazmak hakkı ile erişiyorken, ilhami sadece okuma erişimine sahiptir.

Bu kayıtları girdikten sonra artık svn projemize apache üzerinden erişebiliriz.

Not: /var/svn/svnpasswd ve /var/svn/svnauth.conf  dosyalarında kayıt güncellemeleri yapıldıktan sonra apache servisinin yeniden başlatılmasına gerek yoktur. svnauth.conf dosyasındaki bir yazım hatasından dolayı tüm kullanıcılar giriş yapamayabilir. Bu durumda apache hata logları incelenmelidir.





Sunucu tarafında bir işimiz kalmadı. Şimdi istemci tarafında yetkili bir svn kullanıcısı ile gerekli alt svn dizinlerini oluşturalım. Bunlar trunk,branches ve tag dizini oalcak.



#  svn mkdir --message "Initial trunk"     --username=ismail    http://192.168.1.100/svn/surgate/trunk
Authentication realm: <http://172.16.45.90:80> surgatelabs svn surgate project realm
Password for 'ismail':

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <http://192.168.1.100:80> surgatelabs svn surgate project realm

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes
Committed revision 1.

Burada parolanızı şifresiz olarak saklamak isteyip istemediğinz soruluyor. Tercih size kalmış. Hayır derseniz her svn işleminde parola girmeniz gerekir. Burada uğraşmamak için yes cevabı veriyoruz.

Aynı şekilde diğer dizinlerde oluşturulur.
#  svn mkdir --message "Initial branches"     --username=ismail    http://192.168.1.100/svn/surgate/branches
#  svn mkdir --message "Initial tags"     --username=ismail    http://192.168.1.100/svn/surgate/tags

  

Son olarak proje artık checkout yapılıp kullanılabilir.

# svn co  --username=ismail http://192.168.1.100/svn/surgate/trunk surgate-trunk
Checked out revision 3.
# cd surgate-trunk/
# touch test.txt
# svn add test.txt
A         test.txt
# svn ci -m "ilk commit"
Adding         test.txt
Transmitting file data .
Committed revision 4.
 

JIRA commit acceptance plugini hakkında

Merhabalar,

Bu yazımda az önce bir svn  projemizde devreye aldığım Jira Commit Acceptance plugini hakkında özet bilgi vermek istiyorum.

Jira Commit acceptance eklentisinin en temel görevi bir commit yapıldığında bu commit işleminin belirli kriterlere uyup uymadığını kontrol etmek. Bizim örneğimizde ise commit logunda jira issue numarası olmayan commitleri reddetmek.
Plugin ile ilgili yapılandırma ekranı aşağıdaki gibidir.

Buradaki en önemli parametre "The log message must contain a valid JIRA issue key(s)" Yani svn commit logunda yazılımcı mutlaka o ilgili JIRA projesinde bu iş ile ilgili bir ticket numarası girmeli.
Eğer commit logunda böyle bir key (Örnek: SURGATE-854) yoksa commit kabul edilmemektedir.


İlgili pluginin aktif edilmesi için hem JIRA hem de SVN'de ayar yapılması gerekiyor. Burada RPM tabanlı Linux dağıtımına kurulu bir JIRA ve SVN için yapılandırma anlatılacaktır.

1. JIRA'daki işlemler

JIRA'ya bu pluginin yüklenmesi gerekiyor. plugin version 1 plugin türü olduğu için jira arayüzünden yüklenemektedir. Yüklemek için

• commitacceptance-1.6.0.jar dosyasını jira'nın kurulu olduğu sunucuya atın.(Dosyayı /root/commitacceptance-1.6.0.jar olara attığınızı kabul ediyorum)
• Jirayı durdurun.
  # /etc/init.d/jira stop
• Root kullanıcısı olarak plugini jira lib dizinine kopyalayın
  # cp /root/commitacceptance-1.6.0.jar /opt/atlassian/jira/atlassian-jira/WEB-INF/lib/
• Jirayı başlatın
  # /etc/init.d/jira start
• Jira arayüzüne admin yetkisine sahip bir kullanıcı olarak girin. Administration->Plugins sayfasında "Commit acceptance" plugin'i görebilirsiniz.
  
  

Commit Acceptance bağlantısını takip ederek Global veya Proje bazlı ayar yapabilirsiniz.

2. SVN'deki işlemler

SVN'deki her bir projenin altındaki hooks dizininde pre-commit scriptleri oluşturularak projenin JIRA ile entegrasyonu sağlanmaktadır. Bunu sağlamak için perl ve python da yazılmış iki script gelmektedir. Burada  perl üzerinden bir anlatım yapacağım.
Öncesinde SVN hooks hakkında biraz bilgi verelim. Her bir svn projesinde hooks diye bir dizin bulunur. Bu dizinde aşağıdaki gibi dosyalar bulunur.

# ls /data/svn/surgateconf/hooks/
post-commit       post-lock.tmpl            post-unlock.tmpl  pre-commit.tmpl  pre-revprop-change.tmpl  start-commit.tmpl
post-commit.tmpl  post-revprop-change.tmpl  pre-commit        pre-lock.tmpl    pre-unlock.tmpl

Buradaki dosyalar sayesinde commit öncesi ve sonrasında aksiyonlar alınabilmektedir. Commit acceptance plugini pre-commit dosyasını kullanarak commit svn'de tamamlanmadan devreye girerek kontrollerini yapmaktadır.

•  Commit acceptance sayfasından commitacceptance-1.4.1-client-scripts.zip dosyasını Linux makinaya indirin. # wget https://maven.atlassian.com/contrib/com/atlassian/jira/ext/commitacceptance/1.4.1/commitacceptance-1.4.1-client-scripts.zip
• Zip'i açın
  # unzip commitacceptance-1.4.1-client-scripts.zip
• SVN scriptlerinin olduğu dizine gidin.
  #cd commitacceptance-1.4.1/perl/svn/
  # ls
  jira-client.pl  pre-commit.bat  pre-commit.sh
   
• jira-client.pl dosyası ve pre-commit.sh dosyası istenilen svn projesinin hooks dizinine kopyalanmalı. Yanlız pre-commit.sh değil pre-commit  olarak kopyalanmalı. Her iki dosya izinleride 755 olmalı. 
• pre-commit dosyasının içeriği aşağıdaki gibidir. Buradaki script yolu dizin proje dizinine göre düzenlenmeli
  # cat pre-commit.sh
  #!/bin/sh
  /usr/bin/perl /Users/nolen/svnrepo/hooks/jira-client.pl $1 $2
• perl paketinin çalışması için perl SOAP Lite paketi kurulmalı.
  # yum install perl-SOAP-Lite
• jira-client.pl dosyasında bulunan aşağıdaki 4 değer mutlaka sizin projenizi ve jira bilgilerinize göre değiştirilmeli
  my $jiraBaseURL = "<JIRA base URL>";
  my $jiraLogin = "<JIRA user name>";
  my $jiraPassword = "<JIRA password>";
  my $projectKey = "<JIRA project key>";
  
  Yukarıdaki SVN işlemlerini commit acceptance yapmak istediğiniz her bir projeye ayrı ayrı uygulamasınız. Bu da demektir ki her bir proje için ayrı bir jira-client.pl dosyası ve bu dosyanın yolunu belirten post-commit dosyasını düzenlemeniz gerekiyor.
  
  Bu işlemlerden sonra commit yaparken ISSUE numarası girmeyen kullanıcılar aşağıdaki gibi bir hata alacaktır.
  
  $ svn ci
  issue girmedik.
  --This line, and those below, will be ignored--
  
  M    deneme.sh
  
  
  Dosyayı kaydedip çıktığımızda aşağıdaki hatayı alacağız.
  svn-commit.3.tmp: 4 lines, 79 characters.
  Sending        deneme.sh
  Transmitting file data .svn: Commit failed (details follow):
  svn: Commit blocked by pre-commit hook (exit code 1) with output:
  Committer: ismail.yenigul
  Commit message: "issue girmedik"
  Commit rejected: No project accepts this commit. Project [SURGATE]: Commit message must contain at least one valid issue key.
  
  svn: Your commit message was left in a temporary file:
  svn:    '/usr/home/ismail/projects/surgateconf40/svn-commit.3.tmp'

Fakat commit loguna  SURGATE-854 gibi bir JIRA issue numarası eklediğimizde commit işlemimiz başarı ile tamamlanacaktır.

SVN trunk,branch,tag hakkında

Sürüm kontrol yazılımı kullanılan yazılım projelerinde çokca trunk,branch ve tag ifadelerini duyarsınız. Burada kısaca aralarındaki farklarından bahsedeceğim.

trunk:

Ana geliştirme alanıdır. Bu alan bir sonraki sürümde yapılacak geliştirmeleri içerir.Buradaki kod alfa seviyesinde bile olmayabilir. Bu yüzden trunk'daki kodlara unstable/karr

branch:

Türkçe olarak çatallama/dallanma/ayrılma anlamlarına gelir.trunk'da geliştirilen kod belli bir seviyeye geldiğinde bir sürüm olarak belirlenir. Sürüm olgunluğuna gelmiş kodun ana geliştirme alanından ayrılması işlemine branch adı verilir. Branch svn deposunda trunk'ın belli bir anına kadarki geliştirmeyi içeren kopyası denilebilir. Genelde branch alma, bir sürüm numarası verilerek yapılır.Örneğin  SurGATE 4.0 sürümü geliştirmesi trunk'da bitti ise aşağıdaki gibi bir komut ile trunk'daki kod SURGATE_4_0_RELEASE olarak ana koldan ayrılmış olur.

$ svn copy https://192.168.0.100/svn/surgate/trunk https://192.168.0.100/svn/surgate/branches/SURGATE_4_0_RELEASE -m "SurGATE 4.0 RELEASE branch" 

Yazılımcılar hiç beklemeden trunk'da yeni özellik geliştirmeye devam ederler.
Bu sayede eğer 4.0 sürümünde bir hata çıkarsa  kolayca  SURGATE_4_0_RELEASE branch'da düzeltilebilir. Branch olmasa idi dosyaların trunk'da 4.0 sürümün çıktığı tarihteki revision numarasına dönmek gerekecekti. Çok fazla dosyanın değiştiği bir projede böyle bir süreci yönetmek imkansız olacaktır.

SURGATE_4_0_RELEASE branch'de düzeltilmiş bir kodu da trunk'a aktarabilirsiniz. Buna merge adı veriliyor. Detaylarına başka bir yazıda değineceğim.

tags

Branch ile benzer özelliklere sahip diyebiliriz. Projenin branch kısmında gerektiğinde bugfix yapılabiliyorken, tag projenin o andaki halinin imajının(snapshot) alınması diyebiliriz. Oluşturulan tag'da hiç bir değişiklik yapılamaz. Tag oluşturmanın amacı projenin belirli bir tarihteki kodlarına erişmektir. Tag = salt okunur, etiketleme

SVN tarafında tag alma ile branch alma aynı şekilde svn copy komutu ile yapılır.

Örnek bir tag alma komutu:


$ svn copy https://192.168.0.100/svn/surgate/trunk https://192.168.0.100/svn/surgate/tags/SURGATE_4_0_RELEASE_TAG -m "SurGATE 4.0 RELEASE Tag" 

Özetle branch'de geliştirme devam edebilir. Fakat tag'da böyle birşey söz konusu değildir.

Ama bir dakika! Hem tag hem de branch alırken svn copy komutunu kullandım. Bu durumda svn hangisinin tag, hangisinin branch olduğunu nasıl ayırt edecek?

Aslında ayırt etmeyecek. Size "yalan" söyledim. svn için branch ve tag aynı şeydir.

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html adresinden alıntı:

"But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch."

Yani svn derki. tag ve branch insanların kafasındaki bir olgudur. Benim için farketmez. Eğer birisi gider tag'ı checkout edip orada geliştirme yapmaya kalkarsa yapabilir. Ama bu artık tag olmaktan çıkar, branch olur ;)

Peki ne diye tags ve branch tanımları var diyeceksiniz? Var çünkü CVS denilen eski sürüm kontrol sisteminde bu iki farklı anlama geliyordu. SVN(Subversion) da ise durum yukarıdaki gibi değişti.