Versiyonlama sistemleri (versioning systems) içerisinde SVN, özellikleri ile açık kaynak kodlu projelerde (Open Source Project) ve çevik takımlarda en çok kullanılanı olmuştur.

Mercurial Versiyonlama Sistemi ile desteklenmiş bir ortamda ise ana depodan (repository) - bu depo SVN, Mercurial olabilir - oluşturulan Mercurial depoları ile her kullanıcı offline olarak kodlarını kendi Mercurial deposuna commit yapabilir. Online duruma geçtiğinde kendi deposunu ana depo ile senkronize hale getirebilir.

Açık kaynak kodlu projelerde benimsenen belli bir depo (repository) yapısı mevcuttur:

Depo (Repository)
|
|
|- Proje_1
|
|-trunk
|-branhces
|-releases/tags
|-site
|-sandbox
|
|-developer_1
|-developer_2

trunk : Geliştirme patikalarının (branch) oluşturulduğu, her zaman deploy edilebilir kodların bulunduğu ana proje hattıdır.

branches : Geliştirmelerin yapılacağı, trunk'dan oluşturulan patikalardır. Trunk'dan oluşturulabilecekleri gibi başka bir patikadan da oluşturulabilirler.

releases / tags : Trunk üzerinde gerçekleştirilen Nightly Builds ve Deploy'lar sırasında oluşturulan patikalardır. Bu patikalar kabul görmüş geliştirmeleri içerir.

site : Projeye ait bilgileri içeren web sayfalarının bulunduğu yerdir. Özellikle Maven ile otomatik olarak oluşturulan raporları içerir.

sandbox : Sandbox (kum havuzu) içerisinde her uygulama geliştiriciye ait klasörler bulunur. Bu klasörler içerisinde uygulama geliştiriciler yapacakları araştırmaları ve denemeleri burada depolar.

Versiyonlama Sistemi Yönetim Kuralları

Aynı proje üzerinde 5 kişiden oluşan takımların geliştirme yaptığını düşünelim. Oluşabilecek kod çakışmalarını ve getireceği sorunları tahmin edebiliriz; kod çakışmaları, birbirlerinin kodlarını ezme, birim ve entegrasyon testlerinden geçememe v.b..

Elimizde Gövde (trunk) ve patikalar (branch) klasörleri ile ilgili katı kurallarımız olursa yaşanabilecek sorunları en aza indirgemiş olabiliriz.

Gövde (Trunk) Yönetimi

Gövde'nin özellikleri

1. Gövde (trunk) her zaman deploy edilebilir olmalı
2. Sağlıklı (Stable) olmalı
3. Üzerinde kod geliştirmesi gerçekleştirilmemeli
4. Birim (Unit Test) ve entegrasyon (Integration Test) testlerinden geçmelidir
5. Gövde Yöneticisi tarafından yönetilmelidir.

Gövde Yöneticisinin Görevleri

1. Nightly Build sonrası Gövde'nin sağlık durumunu sürekli takip etmelidir
2. Testleri bozan kod aktarımlarında (merge), aktarımın hangi takım tarafından yapıldığını tespit etmelidir.
3. Sorun tespit ederse hemen ilgili takımın lideri ile irtibata geçip hatalı kodu düzelttirmelidir.

Geliştirme Patikalarının (Branch) Özellikleri

Gövde üzerinde kod geliştirilmesi yapılmayacaksa nerede yapılacak? Bunun için patikalar yardımımıza koşmaktadır. Çevik süreçlerde bir projenin planlama toplantılarında verilen Hikaye Puanları (Story Points) projenin kaç sprint'den oluşacağı ver her sprint'de hangi hikayelerin (Story) bulunacağı belirlenir. Belli büyüklükteki hikayeleri ise görevlere (Task) böleriz.

İlgili proje için Gövde'den (trunk) bir Patika (branch) oluşturalım. Bir takım birden fazla uygulama geliştiriciden oluşursa ve projeye ait hikayeler paralel olarak geliştirilirse Gövde'de yaşadığımız sorunlarla Proje Patika'sında da karşılaşmayacak mıyız?

Evet karşılaşacağız.Çözüm ne olacak peki?

Çözüm 1: Takım içerisindeki tüm geliştiriciler tek bir hikayeye odaklanacak.
Çözüm 2: Proje Patikasından (Project Branch) Hikaye Patikaları (Story Branch) oluşturulur, her hikaye kendisine ait patkida geliştirilir. Onaylanmış hikayeler Proje Patikasında birleştirilir.

Proje Patikasının Özellikleri

1. Gövde'den (Trunk) veya başka bir patikadan oluşturulurlar.
2. Üzerinde sadece önceliği en yüksek hikayenin geliştirmesi yapılabilir veya her hikaye kendisine ait patikada geliştirilir.
3. Takım içerisinden bir kişi Proje Patikasının yöneticisi olarak seçilmelidir.
4. Üzerinde birim testler (Unit Test) çalıştırılmalıdır.

Proje Patikası Yöneticisinin Görevleri

1. Proje patikasının sağlıklı (stable) olmasını sağlar
2. Sürekli Entegrasyon (Continuous Integration) ile birim testlerin periyodik olarak çalıştırılmasını sağlar
3. Hikaye patikalarından (Story Branch) gelen aktarımların (merge) düzgün yapıldığını kontrol eder
4. Hatalı aktarımı yapan kişiyi uyarır, sorunun çözülmesini sağlar
5. Kabul gören hikayelerin, Gövde'ye (Trunk) aktarımını gerçekleştirir.
6. Belli periyodlarla Gövde'deki değişiklikleri Proje Patikası'na aktarmalıdır.

Kod Aktarımını İlk Yapan Kraldır

Çevik takımların bulunduğu geliştirme ortamında takımların birbirlerinin kod aktarımlarını bozmaları kaçınılmazdır. En önemli kuralımız Gövde'nin (Trunk) her zaman deploy edilebilir bütün testlerden geçmiş olmasıdır. Bu kural dahilinde bir T2 takımı, tüm testlerden geçmiş bir T1 takımının aktarımını bozuyorsa o sorunu çözmek T2 takımının görevidir. Bu yüzden T1 takımını kral olarak ilan edebiliriz.


Kaynaklar
1. InfoQ : Version Control for Multiple Agile Teams : Henrik Kniberg

GIT versiyonlama sistemi üzerine yazılmış güzel bir yazı.

"However, I do contribute to quite a lot of them. One of the problems when you do not have write access to the original SCM repository, your patches and changes start getting outdated / conflicted / complicated and it becomes hard to keep up with the changes to the original SCM,

• of your patches, some go through as they are, some with some changes while some do not at all.
• the original repository is in continues change as well.

git Seems to tackle the issue. I have come across with Taki’s blog on CVS to GIT and back that explains how to address the problem in detail. Although the blog focuses on “CVS” it should be pretty easy apply the same for SVN and GIT (over GIT)."

Hasan Ceylan (http://tr.linkedin.com/in/hasanceylan) tarafından yazılan yazının devamı için buraya gidebilirsiniz.

Projenin kullanımı;
Hizmetten faydalanabilmeniz için üye olmanız gerekiyor. Web sitesine girerek üyelik formunu doldurmalısınız. Ayrıca Sun Developer Network(SDN) hesabınız var ise buradaki email adresinizle hemen üye olabilirsiniz.

Üye olduktan sonra My Page bölümünden projelerinizi yönetebilirsiniz. En fazla 5 proje oluşturabiliyorsunuz.
Netbeans ile kullanımı ise şöyle;
Kenai project netbeans 6.7 sürümüden sonra entegre olarak gelmekte. Yeni bir proje oluşturmak için File menüsünden Open->Kenai project diyoruz. Açılan pencereden Create Project e basıyoruz.



Açılan pencerede resimde gördüğünüz gibi proje bilgilerini giriyoruz. Resimde gördüğünüz gibi proje isimleri sadece küçük karakterlerden oluşmalıdır.



Proje ismini küçük harflerle girdikten sonra next diyoruz gelen pencereden Netbeans üzerinde önceden oluşturduğunuz projeyi browse ile bulup gösteriyoruz. Bu bizim local depomuz oluyor. Sonra next diyoruz.



Finish dediğinizde girdiğiniz bilgilerle kenai de yeni bir proje oluşturulacak. Bir süre beklemeniz gerekli.





Bu ekranı gördüğünüzde projeniz başarı ile oluşturulmuş demektir. şimdi bu pencereyi kapatıp kod üzerinde düzenlemeler yapabiliriz.



Yaptığınız değişikliklerden sonra kenai sunucusundaki kod fakları renklendirme ile gösterilmektedir. Yapmak istediğiniz kısmi geri alımlarıda üzerlerine tıklayarak yapabilirsiniz.



Proje üstünde yaptığınız değişiklikleri kenai sunucusuna göndermek içinse proje ismine sağ tıklayıp Kenai->Versioning actions->Commit... e basıyoruz açılan pencerede hangi dosyalara ne değişiklikler yapılacağının ayrıntısını görebiliyoruz. Commit Message bölümüne bu commit ile ilgili detayları yazabilirsiniz.



İşlem bittikten sonra detaylar email adresinize gelecektir.

1. Versiyon Kontrol Sistemleri

Büyük olsun yada küçük olsun tüm şirketlerde, şirket içerisindeki dökümanların akışının ve arşivlenmesinin kontrolü için kullanılan bir sistem vardır. Bu sistem bilgisayar ortamında çalışan bir programdan yada belgeleri raflarda arşivleyen ve belge akışını sağlayan kişilerden oluşabilir.

Bu amaçla kullanılan bilgisayar programlarına en çok yazılım şirketlerinde rastalanmaktadır. Çünkü yazılımcılar gün içinde sürekli kodlarda ufak değişiklikler yapmaktadırlar. Gerektiğinde dosyaları eski tarihteki versiyonlarına geri döndürmektedirler. Bunları yaparken diğer yazılımcıların etkilenmemesi gerekmektedir. İşte bu anda devreye giren bu programlar bir dosya üzerinde farklı kullanıcılar tarafından aynı anda yapılan değişikliklerin birbirini yok etmesini engeller.

Günümüzde yazılım şirketlerinde çoğunlukla CVS (Concurrent Versions System), Subversion ve MS SourceSafe sistemleri kullanılmaktadır. Özellikle CVS sistemi açık kaynak kodlu (Open Source) bir proje olduğu için açık kaynak kodlu olarak geliştirilen projelerde kullanılmaktadır. Bu tür projelere http://sourceforge.net/adresinden ulaşabilirsiniz.

2. Subversion Sistemi

2000 yılından önce Collabnet firması ( http://www.collab.net/) CVS'e alternatif bir versiyonlama sistemi geliştirmeye kararverir. İlk geliştirilen SourceCast sistemi temelde CVS sistemini kullanmaktaydı. Bu nedenle CVS sisteminde var olan kısıtlamalar bu yeni sistemde de görüldü. Bunun üzerine Collabnet firması tarafından CVS'den daha iyi bir sistem geliştirilmeye karar verildi.

14 aylık kodlama döneminden sonra geliştirilen Subversion sistemi 31 Ağustos 2001 tarihinde hizmet vermeye başladı. Açık kaynak kodlu (Open Source) olan Subversion sistemi ücretsiz olarak indirilebilir, kodlarında istenilen değişiklik yapılabilir.

3. Subversion Sisteminin Özellikleri

• Klasör Versiyonlama

CVS sistemi sadece dosyaları versiyonlar. Subversion sistemi ise dosyalarla birlikte klasörlerinde versiyonlanmasını sağlar.

• Atomik Güncelleme :

Yapılan değişikliler ya tümü birden gönderilir ya da azar azar gönderilir. Bu özellik uygulama geliştiricilerin yapılan değişiklikleri bir yığın olarak sunucuya göndermesini sağlar. Böylece değişikliklerin sadece bir bölümünün gönderilmesinden kaynaklanan problemlerin oluşması engellenmiş olunur.

• Versiyon Bilgileri:

Subversion sisteminde her dosya ve klasör kendisine ait “ anahtar-değer ” çiftlerinden oluşan özellikler içermektedir. Bu özellikler, dosya içerikleri gibi versiyonlama işlemine tabi tutulabilir.

• Ağ Üzerinden Erişim

Subversion sistemi Apache HTTP sunucusuna ek bir modül olarak eklenebilir. Bu özellik Subversion sistemine kararlılık ve farklı platformlarda çalışabilirlilik açısında büyük avantaj kazandırmaktadır. Böylece Subversion sistemi, entegre edildiği sistemin sağladığı güvenlik, kullanıcı kontrolü gibi servisleri kullanabilir duruma gelir.

4. Subversion Kurulumu

Subversion sisteminin kurulumunu Windows işletim sistemi üzerinde gerçekleştireceğiz. Bunun için http://subversion.tigris.org/ adresi üzerinden svn paketini indirmeniz gerekmektedir. İlgili Windows Binary paketini istediğiniz dağıtıcıya göre indirebilirsiniz. İndirme işlemi bittikten sonra kurulum dosyasını çalıştıralım. Önümüzde kurulum adımlarını gösteren pencere çıkacaktır. Burada gerekli işlemleri yaptıktan ve Subversion sistemini kuracağımız dizini belirttikten sonra kurulum gerçekleşecektir. Kurulumu test etmek için “Command Prompt” da

svn --version

yazalım. Çalıştırdığımızda aşağıdaki gibi bir sonuç alırız.

Şekil – 1 : Subversion sistemi

Subversion sistemi çalıştığına göre kaynak kodların ve versiyonlama işlemi ile ilgili bilgilerin tutulacağı bir tane depo (repository) oluşturalım. Bunun için aşağıdaki gibi bir komut çalıştırmamız gerekiyor.

svnadmin create c:repository

Bu işlem sonrasında Şekil-2 deki gibi dizin yapısı oluşur.

Şimdi sıra var olan bir projeyi depoya (repository) eklemeye geldi. “C:TEMP” dizini altında file_1.txt , file_2.txt , file_3.txt ve file_4.txt dosyalarından oluşan “ project1” isimli projeyi depoya ekleyelim. Proje ekleme işlemleri için “ svn import “ komutu kullanılır.

svn import --message " " c:tempproject1 file:///c:/repository/project1

Komut sonucunda aşağıdaki ekran karşımıza gelir.

Subversion sistemi yeni oluşturulmuş bir depoya (repository) dosya ya da klasör eklendiğinde değişiklik (revision) numarasını 1 yapar. Daha sonra yapılacak olan değişiklikler sonucu değişiklik (revision) değeri artacaktır. (Değişiklik değeri ile ilgili daha sonraki yazılarda detaylı şekilde değinilecektir.) Subversion dosyalar üzerinde yapılmış olan değişiklikleri değişiklik (revision) değerine göre kontol eder.

“Project1” isimli projenin depoya (repository) eklenip eklenmediğine bakalım.

svnlook tree c:repository

komutunu çalıştırdığımız zaman Şekil-4'de ki gibi depoya (repository) eklenenleri görebiliriz.

Şeklik - 4 : Depoda (repository) var olanların listesi

5. Apache HTTP Server'ının Kurulum

Subversion sisteminin Apache Server ile entegrasyonunu Apache Server'ın 2.0.49 versiyonunda gerçekleştireceğiz. Önce http://httpd.apache.org/download.cgisitesinden Windows işletim sistemi için ilgili Apache Server'ı indirelim. Kurulum programını çalıştırarak kurulumu gerçekleştirdikten sonra “...Apache GroupApache2conf” dizini altında bulunan httpd.conf dosyasında birkaç değişiklik yapmamız gerekiyor.

Httpd.conf dosyasında aşağıdaki satırın başındaki ‘ # ' işaretini kaldırarak satırı aktif yapalım.

#LoadModule dav_module modules/mod_dav.so

Bu satırdan sonra yeni bir satıra

LoadModule dav_svn_module modules/mod_dav_svn.so

ekleyelim.

Şimdi Subversion sistemini kurduğumuz dizindeki “httpd” klasörü içerisindeki “mod_dav_svn.so” dosyasını “...Apache GroupApache2modules” dizinine kopyalayalım.

“ httpd.conf ” dosyasısının en sonuna

DAV svn SVNPath c:/repository/

tanımlamasını yapalım ve dosyayı kaydedelim.

Apache Server'ını başlattıktan sonra bir web görüntüleyicisinde (web browser) http://sunucu_ismi/repositorybağlantısını yazdığımızda Şekil-5 teki gibi depoya (repository) eklenenleri dizin yapısı şeklinde görüntüler.

Subversion sistemi ile Apache Http sunucusunu entegrasyonunu gerçekleştirdik.

6. Projeyi Kullanıcı Makinasına İndirmek

Depodaki bir projeye dahil olmak için önce bu projenin kullanıcı makinasına depodan çekilmesi gerekiyor. Bunun için “ svn checkout ... ” komutu kullanılır. Bu işlemi http üzerinden gerçekleştirmek için aşağıdaki komutu çalıştıralım.

svn checkout http://localhost/repository/project1 c:pro_1

Burada “ http://localhost/repository/project1“ adresindeki dosya ve dizin yapısını “ c:pro_1 ” altına kopyalar.

Buradaki A harfleri ilgili dosyanın eklendiğini göstermektedir.

Dizin yapısı Şekil-7 deki gibidir.

Şekil-7 Kullanıcı makinada oluşan dizin yapısı

Projeyi kopyaladığımızda otomatik olarak “ .svn ” klasörü oluşur. Bu klasör içerisinde her değişiklik (revision) numarasına ait değişiklikler bulunmaktadır. Ayrıca kullanıcının yaptığı yerel değişiklikler burada saklanmaktadır. Kullanıcı bilgisayar ağına bağlı olmadığı zamanlar yaptığı değişiklikleri, bilgisayar ağına bağlandığında depoya (repository) yükleyebilir. Bu esnada gerekli tüm bilgiler “.svn” içerisinden alınmaktadır.

Taner Diler
taner.diler[et]gmail.com