Versiyon Kontrol Sistemi Nedir ?

Versiyon Kontrol Sistemi (VCS), revizyon kontrol (revision control) veya kaynak kontrol (source control) diye de geçip, değişiklik yönetim sistemi anlamına gelmektedir. Bir ya da daha fazla dosya üzerinde yapılan değişiklikleri kaydeden ve daha sonra belirli bir sürüme geri dönebilmenizi sağlayan bir sistemdir.

“Sürüm kontrolü” terimi genellikle programcılarla ilişkilendirilirken, yazarlar, gazeteciler ve hatta üniversite öğrencileri için de aynı derecede önemlidir. Belge revizyonlarını ve sürümlerini otomatik olarak takip eden yaygın hizmetlere örnekler arasında Google Docs ve DropBox bulunur.

Amaçları Nelerdir ?

Geliştiricilerin, kod değişikliklerini takip etmelerini sağlamak.
Geliştiricilerin, kod değişiklik geçmişini görmelerini sağlamak.
Geliştiricilerin, aynı kod dosyalarında aynı anda çalışmasına izin vermek.
Geliştiricilerin, kodlarını dallanma yoluyla ayırmalarına izin vermek.
Farklı dallardan (branch) kodu birleştirmek.
Geliştiricilerin, çakışmalarını gösterir ve bunları çözmelerine izin vermek.
Geliştiricilerin, değişikliklerini önceki bir duruma döndürmelerine izin vermek.

Ne için Kullanırız ?

Bir dosyanın değişik sürümlerini korumak istiyorsanız, Sürüm Kontrol Sistemi (VCS) kullanmanız çok akıllıca olacaktır. VCS, dosyaların ya da bütün projenin geçmişteki belirli bir sürümüne erişmenizi, zaman içinde yapılan değişiklikleri karşılaştırmanızı, soruna neden olan şeyde en son kimin değişiklik yaptığını, belirli bir hatayı kimin, ne zaman sisteme dahil ettiğini ve daha başka pek çok şeyi görebilmenizi sağlar. Öte yandan, VCS kullanmak, bir hata yaptığınızda ya da bazı dosyaları yanlışlıkla sildiğinizde durumu kolayca telâfi etmenize yardımcı olur. Üstelik, bütün bunlar size kayda değer bir ek yük de getirmez.

Versiyon Konrol Sistemlerinin Evrimi

İlk olarak 1972 yılında SCCS (Source Code Control System) yayınlandı. SCCS, Unix sistemler için defacto haline gelmişti. 1982 yıllarında da yine Özgür Yazılım Vakfı tarafından, GNU RCS (Revision Control System) yayınlandı ve oldukça popüler hale geldi. Bu gösteriyor ki 1970’li yıllarda böyle bir sisteme ihtiyaç duyulmaya başlanmış. İlk nesil versiyon kontrol sistemleri o tarihlerde başladı diyebiliriz. ikinci nesilin başlangıcı SVN ile 1990’larda ve 2005 yılıda da dağıtık sistem ile beraber üçüncü nesil sürüm kontrol sistemleri piyasaya çıkmıştır.

Sürüm Kontrol Sistemleri Arasındaki Farklar Nelerdir?

Bu kadar sürüm kontrol sistemlerin piyasaya çıkmasında bazı sebepler vardır. Bu arada wikipedia’ da hepsininin kıyaslaması bulunmaktadır.

→ https://en.wikipedia.org/wiki/Comparison_of_version_control_software#History_and_adoption

Sürüm kontrol sistemlerini aşağıdaki üç kritere göre kategorize edebiliriz.

➧ Depo (Repository) Konumu

➮ Yerel (local)

➮ Merkezi (centralized)

➮ Dağıtık (distributed/decentralized)

➧ Çakışma (Conflict) Çözümü

➮ Locking (Kilitleme)

➮ Merge-before-commit (Commit öncesi merge)

➮ Commit-before-merge (Merge öncesi commit)

➧ Dosya veya Dosya Kümesi İşlemleri

Local(Yerel), Merkezi (Central) ve Dağıtık (Distributed) Sistemler

Yerel Sürüm Kontrol Sistemleri

Çoğu insan, dosyaları bir klasöre (akılları başlarındaysa tarih ve zaman bilgisini de içeren bir klasöre) kopyalayarak sürüm kontrolü yapmayı tercih eder. Bu yaklaşım çok yaygındır, çünkü çok kolaydır; ama aynı zamanda hatalara da alabildiğine açıktır. Hangi klasörde olduğunuzu unutup yanlış dosyaya yazabilir ya da istemediğiniz dosyaların üstüne kopyalama yapabilirsiniz.

Bu sorunla baş edebilmek için, programcılar uzun zaman önce, dosyalardaki bütün değişiklikleri sürüm kontrolüne alan basit bir veritabanına sahip olan yerel sürüm kontrol sistemleri geliştirdiler.

En yaygın VCS araçlarından biri, bugün hâlâ pekçok bilgisayara kurulu olarak dağıtılan, rcs adında bir sistemdi. Ünlü Mac OS X işletim sistemi bile, Developer Tools’u yüklediğinizde, rcs komutunu kurmaktadır. Bu araç, iki sürüm arasındaki yamaları (yani, dosyalar arasındaki farkları) özel bir biçimde diske kaydeder; daha sonra, bu yamaları birbirine ekleyerek, bir dosyanın belirli bir sürümdeki görünümünü yeniden oluşturur.

Merkezi Sürüm Kontrol Sistemleri

İnsanların karşılaştığı ikinci büyük sorun, başka sistemlerdeki programcılarla birlikte çalışma ihtiyacından ileri gelir. Bu sorunla başa çıkabilmek için, Merkezi Sürüm Kontrol Sistemleri geliştirilmiştir. Bu sistemler, meselâ CVS, Subversion ve Perforce, sürüm kontrolüne alınan bütün dosyaları tutan bir sunucu ve bu sunucudan dosyaları seçerek alan (check out) istemcilerden oluşur. Bu yöntem, yıllarca, sürüm kontrolünde standart yöntem olarak kabul gördü.

Bu yöntemin, özellikle Yerel CVS‘lere göre, çok sayıda avantajı vardır. Örneğin, bir projedeki herkes, diğerlerinin ne yaptığından belirli ölçüde haberdardır. Sistem yöneticileri kimin hangi yetkilere sahip olacağını oldukça ayrıntılı biçimde düzenleyebilirler; üstelik bir Merkezi CVS‘yi yönetmek, her istemcide ayrı ayrı kurulu olan yerel veritabanlarını yönetmeye göre çok daha kolaydır.

Ne var ki, bu yöntemin de ciddi bazı sıkıntıları vardır. En aşikar sıkıntı, merkezi sunucunun arızalanması durumunda ortaya çıkacak kırılma noktası problemidir. Sunucu bir saatliğine çökecek olsa, o bir saat boyunca kullanıcıların çalışmalarını sisteme aktarmaları ya da çalıştıkları şeylerin sürümlenmiş kopyalarını kaydetmeleri mümkün olmayacaktır. Merkezi veritabanının sabit diski bozulacak olsa, yedekleme de olması gerektiği gibi yapılmamışsa, elinizdeki her şeyi —projenin, kullanıcıların bilgisayarlarında kalan yerel bellek kopyaları (snapshot) dışındaki bütün tarihçesini— kaybedersiniz. Yerel CVS’ler de bu sorundan muzdariptir —projenin bütün tarihçesini tek bir yerde tuttuğunuz sürece her şeyi kaybetme riskiniz vardır.

Dağıtık Sürüm Kontrol Sistemleri

Bu noktada Dağıtık Sürüm Kontrol Sistemleri devreye girer. İstemciler (kullanıcılar) dosyaların yalnızca en son bellek kopyalarını almakla kalmazlar: yazılım havuzunu (repository) bütünüyle kopyalarlar. (Git, Mercurial, Bazaar ya da Darcs örneklerinde olduğu gibi)

Böylece, sunuculardan biri çökerse, ve o sunucu üzerinden ortak çalışma yürüten sistemler varsa, istemcilerden birinin yazılım havuzu sunucuya geri yüklenerek sistem kurtarılabilir. Her seçme (checkout) işlemi esasında bütün verinin yedeklenmesiyle sonuçlanır.

Dahası, bu sistemlerden çoğu birden çok uzak uçbirimdeki yazılım havuzuyla rahatlıkla çalışır, böylece, aynı proje için aynı anda farklı insan topluluklarıyla farklı biçimlerde ortak çalışmalar yürütebilirsiniz. Bu, birden çok iş akışı ile çalışabilmenizi sağlar, ki bu merkezi sistemlerde (hiyerarşik modeller gibi) mümkün değildir.

Çakışma (Conflict) Çözümü

Check out sırasında bir dosyayı kilitlemek, çakışmaların eşzamanlı kod düzenlemesinden kaynaklanmadığından emin olmak için ilk nesil VCS’lerin kullandığı yöntemdi. Bir dosya kilitlendiğinde, kullanıcı bu dosyayı yeniden kontrol edip kilidi açılana kadar dosyaya erişme veya değişiklik yapma hakkını talep eder. Bu, birden fazla geliştiricinin çakışan (conflict) kod üretememesini sağlar, ancak çoğu durumda işleri engeller ve zaman kayıpları bolca olur.

Commit öncesi merge (Merge-before-commit) işlemi, SVN gibi ikinci nesil VCS’ler tarafından kullanılan yöntemdir. Bu işlemin taahhütü bir geliştirici kod üzerinde bir değişiklik yapmadan önce sunucudaki en güncel sürümle merge(birleştirme) yapması gerektirir. Bu yapılır akabinde commit yapılabilirdi. Yeni nesil VCS’lerde, önce birleştirme ihtiyacı ortadan kalkmıştır, commit-before-merge şeklinde çalışmaktadır.

SVN / Git / Mercurial / Bazaar Kıyaslama

VCS	Depo Konumu	Conflict Çözümü
SVN	Merkezi	merge-before-commit
Git	Dağıtık	commit-before-merge
Mercurial	Dağıtık	commit-before-merge
Bazaar	Dağıtık	merge-before-commit

Versiyon Kontrol Sistemleri (VCS)