Source Control

Versiyon kontrolü nedir?
Bir dokümanın olusum sürecini ve değisik versiyonların takibi ve arsivlenmesi için kullanılan
metot ve sistemlere versiyon kontrolü adı verilir. Genelde yazılım sektöründe projelerin
yönetimi için versiyon kontrol sistemleri kullanılır. Birden fazla programcının kod paylasımı
ve yapılan değisiklerin takibi için bir versiyon kontrol sisteminin kullanımı kaçınılmazdır.
Daha sonra yakından inceleyeceğimiz gibi olusturulan bir yazılım ürününün (program)
değisik versiyonlarının olusturulması ve bu versiyonlardaki hataların (bug) giderilmesi için
kullanılan versiyon kontrol sistemi değisik araçlar ve yöntemler ihtiva etmektedir. Bu
metotlar kullanılarak yazılım süreci desteklenir.
Bir versiyon kontrol sistemini depo gibi düsünebiliriz. Olusturulduğumuz her doküman bu
depoya gönderilir. Depo, dokümanların ve değisik versiyonlarının nasıl yönetileceğini bilir.
Programcı olarak deponun içinde neler olup, bittiğini bilmek zorunda değiliz. Sadece bir
dokümana gerek duyduğumuz zaman depoya basvurarak, gerekli dokümanı ediniriz. Bu
doküman üzerinde değisiklik yapabilir ve değistirilen dokümanı tekrar depoya gönderebiliriz.
Bu esnada dokümanın değisik versiyonları olusur. Olusan değisik versiyonlar üzerinde de
kafa yormamıza gerek yoktur, çünkü depo bu versiyonların yönetimi üstlenir. Depoya
danısarak, bir dokümanın tarihçesini edinebiliriz. Depo hangi dokümanın kim tarafından ne
zaman değistirildiğini her zaman bilir. Kayıtlarda iz bırakmadan bir doküman üzerinde
değisiklik yapmak mümkün değildir.
Versiyon kontrol sistemlerinde kullanılan depolara repository ismi verilir. Çoğu versiyon
kontrol sistemi bünyelerinde bilgibankaları kullanarak repository olusturmaktadırlar. Örneğin
Subversion’da Berkley DB bilgibankasını kullanarak bir repository olusturulabilir. Bunun
yanı sıra versiyon kontrol sistemi tarafından normal sistem dosyaları (file repository)
kullanılarak da repository’ler olusturulabilir. Bu gereksinimlere bağlı olarak yapılması
gereken bir seçimdir.
Versiyon kontrol sisteminin merkezinde bir repository olduğu için, bu repository’nin güvenli
bir bilgisayar üzerinde olmasına dikkat edilmelidir. Bu bilgisayar erisilemez durumda
olduğunda yada en kötü ihtimalle bozulduğunda, tüm versiyon kontrol sistemi çalısmaz hale
gelecektir. Mutlaka düzenli aralıklarla repository’nin kopyası (backup) alınmalıdır.
Kod paylasımını kolaylastırmak için çoğu modern versiyon kontrol sistemleri bilgisayar ağı
üzerinden kullanılabilir sekilde çalıstırılabilir (network enabled). Bu sekilde programcının
bulunduğu yer önemini yitirmekte ve bilgisayar ağı mevcut olduğu sürece, yerden bağımsız
olarak versiyon kontrol sistemi kullanılabilmektedir. Programcı bilgisayar ağı üzerinden
versiyon kontrol sisteminin barındırdığı repository’ye bağlanarak, kod paylasımını
gerçeklestirebilir.
Peki bir programcı bilgisayar ağı üzerinden erisim olmadığı durumlarda çalısmasını nasıl
devam ettirebilir? Modern versiyon kontrol sistemleri devre dısı mod (disconnected yada
offline mode) olarak tabir edebileceğimiz çalısma tarzını desteklemektedirler. Programcı is
yerinden ayrılmadan önce üzerinde çalısmak istediği projeyi repository’den alır ve
bilgisayarına yükler. Programcı böylece kendi bilgisayarında projenin bir kopyasına sahip
olur (working copy). Gün içinde programcı proje üzerinde çalısarak, bir takım değisiklikler
yapar. Programcı ertesi gün tekrar ofise gelerek, yaptığı değisiklikleri repository ile
senkronize eder.
Bir versiyon kontrol sistemi seçilirken, programcı ekibinin gereksinimleri göz önünde
bulundurulmalıdır. Her versiyon kontrol sistemi istenilen esnekliği sağlayamayabilir.
Edindiğim tecrübeler doğrultusunda Subversion versiyon kontrol sisteminin, programcı ekibin
gereksinimlerine büyük oranda cevap verebileceğini söyleyebilirim.

Subversion
Mimari:


Subversion1 açık kaynaklı (open source) versiyon kontrol sistemidir.
Bazı özellikleri söyledir:
-Subversion CVS2 örnek alınarak yapılmıstır. Amaç CVS’de daha iyi bir versiyon
kontrol sistemi olusturmaktı. Bu yüzden Subversion birçok CVS özelliğine sahiptir.
-Subversion dizinlerin de normal dosyalar gibi versiyonlarını olusturur.
-Kopyalama, silme ve isim değistirme islemlerinde Subversion tarafından yeni
versiyonlar olusturulur.
-Subversion’da yapılan islemler ya hep ya hiç prensibiyle gerçeklesir, yani commit’ler
atomiktir (atomic commits).
-Dal (branch) ve etiket (tag) olusturulması copy islemi kullanılarak gerçeklestirildii
için kısa sürer.
-File locking mekanizması kullanılarak, dosyaların üzerinde degisiklik yapılması
engellenebilir.
-Subversion bir Apache webserver üzerinde erisilebilir hale getirilebilir.
-Svnserve komutuyla Subversion, versiyon kontrol serveri olarak görev yapabilir.
Nasıl Çalışır?

Kopyala-değiştir-Birleştir

TEMEL KOMUTLAR
Checkout: Çalışma kopyası almak için
Commit: Çalışma kopyasında yaptığımız değişiklik
ve ilaveleri depoya göndermek için
Update: Depodan diğer geliştiricilerden gelen son
değişiklikleri alıp çalışma kopyamızı, güncellemek

Repository (Depo)
Subversion bünyesinde tüm dokümanlar ve bu dokümanların değisik versiyonları repository
ismini tasıyan bir depoda tutulur. Kurulum esnasında nasıl bir tip repository kullanılması
gerektiği belirlenir. Subversion’ın ilk sürümleri Berkeley DB bilgibankasını repository olarak
kullanırdı. Subversion’in yeni sürümlerinde FSFS ismini tasıyan ve dokümanları dosya
sisteminde (filesystem) bir dosya içinde tutabilen alternatif bir repository türü bulunmaktadır.
Bu iki repository türü arasında seçim yapılabilir. Hangi tür repository’nin kullanılması
gerektiği gereksinimler doğrultusunda belirlenmelidir.
Bir repository, dokümanların yer aldığı bir dizin ağacı olarak düsünülebilir. Her ağaç,
barındırdığı doküman ve dizinlerin belli bir zamanda yapılan değisiklikler sonucu olusan
versiyonlarını ihtiva eder. Bu versiyonlar kullanıcıların yaptığı islemler sonrasında olusurlar
ve Subversion jargonunda revizyon (revision) olarak isimlendirilir.
Working Copy (Üzerinde Çalısılan Kopya)
Bir proje bünyesinde olusan tüm dokümanlar Subversion tarafından olusturulan repository
içinde yeralır. Bir programcının kod üzerinde çalısabilmesi için, repository’de bulunan
dokümanların bir kopyasına sahip olması gerekmektedir. Programcının sahip olduğu bu
dokümanlara working copy adı verilir. Programcı yaptığı her değisikliği repository’ye
gönderebilir (commit) ve en son yenilikleri repository’den alabilir (update).
Tag (Etiket)
Subversion’da değisik versiyonların revizyon numarası üzerinden yönetildiğini gördük. Sonuç
itibariyle revizyon numarası bir rakam olduğu için akılda kalıcı olmayabilir. Programcılar
arasında değisik program versiyonları için version1, release2 gibi isimlerin kullanılması daha
yaygındır.
Subversion ile projenin belirli bir asamasında, o zamana kadar yapılmıs tüm çalısmaları bir
etiket altında toplamak amacıyla tag konsepti uygulanabilir. Herhangi bir isim seçilerek
projenin belirli bir asamaya ulastığını ifade etmek için etiket (tag) olusturulur. Bu bir
fotoğrafın çekilmesi gibi o anki anlık görüntünün alınması anlamına gelir.
Etiket ismi kullanılarak, projenin bu asamadaki durumu daha sonra repository’den
edinilebilir. Tag kullanılarak olusturulmus versiyonlar repository’den sadece okuma
(readonly) amacıyla alınmalıdır. Yapılacak herhangi bir değisiklik yine aynı tag altında
kayıtlandığı için, etiket ile olusturulan anlık görüntü bozulmus olur.
Branch (Dal)
Bir iterasyon sonunda müsteriye yeni bir sürüm olusturarak teslim ettiğimizi düsünelim.
Müsteri bu sürümü kullanırken, bizde yeni bir iterasyonda projeye devam ediyor olalım.
Sürüm için yeni bir versiyon tagı (etiket) kullandık, örneğin v.0.1. Müsteri programı
kullanırken bir hatanın olustuğunu bize bildirmis olsun. Bu durumda üzerinde çalıstığımız ana
kod üzerinde hatayı gidererek, müsteriye yeni bir sürüm veremeyiz, çünkü üzerinde
çalıstığımız ana kod çalısır ve stabil durumda değil yada yeni implementasyonlar
tamamlanmadı. Bu durumda yapılabilecek tek sey: v.0.1 versiyonunu baz alarak, yeni bir dal
olusturmamız ve hatayı o dal üzerinde gidermemiz gerekiyor. Yeni bir dal olusturduğumuz
zaman ana koda paralel olarak baska bir versiyonu baz alan yeni bir yazılım kanadı olusur.
Trunk x (zaman) ekseninde ilerleyen ana kod
dalıdır. Olusan hataları gidermek için trunka paralel olarak yeni bir dal (branch) olusturmamız
gerekir. Hatalar bu dal üzerinde giderildikten sonra yeni bir versiyon (v.0.2) olusturduktan
sonra paralel dal üzerinde yaptığımız değisiklikleri trunka aktarırız (merge). Bu islemin
ardından hem ana dal rahatsız edilmeden hata giderilerek yeni bir sürüm olusturulur, hemde
hataların giderilmesi için yapılan değisiklikler merge metoduyla ana dala aktarılır.
Trunk (Ana dal)
Trunk repository’de bulunan ana kod dalıdır. Yapılan tüm değisiklikler trunk içinde yeralır.
Tüm etiket ve dallar trunk üzerinden gerçeklestirilir.
Merge (Birlestirme)
Eğer belirli bir sürüm için hata gidermemiz gerekiyorsa, trunka paralel yeni bir dal (branch)
olusturmamız gerekiyor. Burada yapılan değisikliklerin tekrar trunka aktarılmasına merge adı
verilir.

SVN kullanım klavuzu için aşağıdaki linke tıklayıp bilgisayarınıza indirebilirsiniz.
http://isezen.com/download/