Subversion, Bazaar ve GIT Üzerine..

rocketraptiye'yi Bazaar üzerinde sunduğumu daha önceki yazılarımdan birinde söylemiştim. Işık Üniversitesi Kulüpler Sunucusu'nda, Parkyeri'nde, Arch Linux Türkiye projelerinde ve kendi yaptığım işlerin bir kısmında Subversion tercih ediliyor. Bunun dışında bir çok sürüm yönetimi sistemi var elbet ve bunlardan en önemlilerini (GIT, Mercurial) araştırdıktan sonra Bazaar kullanmaya karar verdim. Bu yazıda bu konuyla ilgili dikkatimi çeken ve önemli bulduğum şeyleri paylaşmaya çalışacağım. Bir çok insanın sürüm yönetimine kavram olarak yabancı olduklarını düşündüğümden çok kısa bir şekilde onu da açıklamak istiyorum.

Sürüm Yönetimi Sistemleri Nedir?

İngilizce'de Version Control System (VCS) olarak geçen, dilimizde iyi anlatabilmek için yukarıdaki gibi uzun olan sürüm yönetimi, bazı yerlerde revizyon yönetimi gibi de kullanılıyor. Sürüm Yönetimi'ni, yazılımın aşama aşama geliştirildiğini düşünürsek, bu aşamaları kayıt altında tutan, istenildiğinde geri dönülmesine olanak tanıyan, aşamalar arasında neler olduğunu kolaylıkla gösterebilen yazılımlar olarak özetleyebiliriz. Geliştirici'nin hayatını kolaylaştırdığı kesin! Bu yazılımlardan neler beklendiğini maddeler halinde yazarsam sanırım daha iyi anlaşılacaktır:
  • Kodda yapılan tüm değişimler birer revizyondur.
  • Revizyonlar arasında değişen dosyalar, dosyalardaki değişiklikler (gerekirse yama olarak) kolayca görüntülenebilmelidir.
  • Herhangi bir revizyondan sonra işler yanlış gittiyse, o revizyona kadar olan kısım geri alınıp hiç bir şey olmamış gibi devam edilebilir.
  • Herhangi bir dosyada yapılan değişiklikler kodun geri kalanından bağımsız olarak geri alınabilmelidir.
  • Birlikte çalışılan projelerde, diğerlerinin yaptığı değişiklikleri alabiliyor olmalı ve bunu yaparken de olabildiğince az (mümkünse sıfır) çakışmaya izin vermelidir.
  • Ek maliyetler getirmemeli, hızlı ve kolay olmalıdır. Mümkünse her platformda çalışmalıdır.
Tüm bunlar bir arada düşünüldüğünde geliştiricinin işlerini kolaylaştıran ve hızlandıran etmenler.. Bu ihtiyaçlara cevap verebilmek adına kullanılabilir durumda bir sürü sürüm yönetimi yapan yazılım var. En meşhuru olan CVS'in, doğal gelişim süreci içinde yetersiz gelmeye başladığı ortaya çıkınca ortaya Subversion çıkmış. Şu anda bir çok ihtiyacı görüyor gibi görünse de ileride yetersiz kalacağını görenler Bazaar, GIT ve Mercurial gibi alternatifler geliştirmişler. Gelin; bu sistemlerin yukarıdaki maddelere ek olarak getirdiklerine bakalım:
  • Sürüm yönetimi için çevrimiçi olmak gerekmemeli! Teslimat (commit), Birleştirme (merge), tarihçe gibi işlemler için herhangi bir sunucuya bağlanmak gerekmemeli.. Kısaca merkezi sisteme hayır!
  • Kod tabanı dağıtık bir yapıda olabilir ve insanlar birbirlerinden değişik kısımları ya da kodun tamamını alabilirler.
  • Her kopya, sürüm kontrolüne ait tarihçe vb. kritik önem taşıyan bileşenleri barındırır.
  • Her kopya aslında yeni bir daldır (branch)!
  • Birleştirme işlemi acı vermeyen, sürekli yaptığımız; hatta zevk veren bir işlem olmalıdır!
  • Çevrimdışı çalışma = hız!
  • Büyük şirketlerde sıkça rastlanan "kod çalışana ve tüm testleri geçene kadar teslim edemezsin!" mantığı yüzünden tüm değişikliklerin tek ve kocaman bir yama olarak gönderilmesi sorunlara yol açabiliyor. Bunun yerine yerel ve küçük küçük teslimatlar yapabilir; daha sonra değişiklikler ana sunucuya teslim edilebilir hale geldiğinde her değişiklik birer revizyon olacak şekilde ana sunucuda yerini alır. Böylece yapılan büyük bir değişiklikte bile atomik değişiklikler geri alınabilir ve rahatlıkla düzeltilebilir.
Peki Alternatifler Neler?

Bunları ve daha fazlasını yapabilen uygulamaların bulunduğu kümeye Dağıtık Sürüm Yönetimi Sistemleri (Distributed Version Control Systems) deniyor. Linus Torvalds, Linux çekirdeğinin geliştirilmesinde kullanılan BitKeeper ile ilgili sorunlar yaşanmaya başlanınca bu konuya kendi çözümünü getirip GIT adında bir yazılım yazmış. Dağıtık Sürüm Yönetimi ve GIT hakkındaki düşüncelerini paylaştığı şu video'nun epey yararlı olduğunu söyleyebilirim.

MercurialArch Linux Türkiye projelerini yönetmek için Samed BEYRİBEY'in önerisiyle denemeye başladık. Başlarda fazla araştırmadığım için oldukça yabancı gelmiş ve ısınamamıştım. Tıpkı GIT gibi "commit", "checkout" vb. alıştığımız anahtar sözcükler yerine başka sözcükler tercih ediliyordu ve bu da kafa karıştırıcı oluyordu. Mercurial, sırf bu yüzden dumur olan insanlara kolaylık olması amacıyla bu sözcükleri içinde bulunduruyor yine de.. Bir süre denedikten sonra bir hayli karışık geldiğinde kullanımından vazgeçtik ve böylece Mercurial defteri kapanmış oldu.

GIT, şu anda bir hayli revaçta olan bir yazılım.. Bir çok özgür yazılım projesi tarafından tercih ediliyor ve sayıları giderek artıyor. Benim GIT'i tercih etmememdeki en büyük sebepler şöyleydi:
  • GIT içerisindeki kodu sunmak için bir sürü ayarla uğraşmak istemedim.
  • GIT'in getirdiği terminoloji öğrenmesi zaman alacak gibiydi.
  • Dökümantasyonu Bazaar kadar açık ve rahat okunabilir değil.
  • Herhangi bir web servisi ile alakası yok.. (Bazaar'ın LaunchPad desteği gibi..)
  • Boş dizinlerin sürüm yönetimi içinde bulunamaması ve içine boş birer dosya koyma zorunluluğu hoşuma gitmedi.
  • Platform bağımsız değil. Windows'da çalışmıyor. (ya da desteği henüz yetersiz)
Öte yandan araştırmamı daha çok Bazaar ve GIT karşılaştırması yapan yazılar üzerinde yoğunlaştırmıştım. Bazaar'ın hoşuma giden özellikleri şöyle:
  • Kodunuzu sunmak için herhangi bir sunucu kurmanıza gerek yok. Zaten varolanlar ile birlikte zaten bir hayli seçeneğiniz var:
    • bzr://,
    • sftp:// (SSH),
    • ftp://, http:// (webdav),
    • file:// (yerel dosya sistemi)
  • Dökümantasyonu (özellikle anlatımı) ve sitesi oldukça etkileyici..
  • LaunchPad desteği sayesinde tek bir komutla servisle etkileşim halindesiniz.
  • Boş dizinler de (doğal olarak) sürüm yönetimine dahiller.
  • Linux, Mac OS X ve Windows'da sorunsuz olarak çalışabiliyor.
Bazaar'la ilgili beni en çok etkileyen şey kodumu sunmak için çok fazla uğraşmama gerek olmamasıydı. Varolan kodumu sürüm yönetimi altındayken kullandığım ağ sunucusu ile sunmam yeterli! Örneğin raptiye'nin kod tabanını nginx ile sunuyorum (http://code.raptiye.org) ve Bazaar kullanan bir kişi http:// protokolü üzerinden kodu dallandırabiliyor!

Bir çok kişi Subversion kullanımına; dolayısıyla da merkezi sisteme alışık olduğundan Bazaar'ı bu şekilde yapılandırıp yarı-dağıtık bir model ile kullanabilirsiniz. Uzaktaki kodu yerelinize indirip (dallandırıp) tüm değişikliklerinizi çevrimdışı olarak kendi bilgisayarınızda yapabilir, dilediğinizce farklara bakıp, tarihçeyle ilgili işlem yapabilir, yerel teslimatlar yapabilirsiniz. İşiniz bittiğindeyse kodun son halini sunucuya gönderebilirsiniz. raptiye'de tek kişi çalıştığım için şu anda bu modeli sıkça uyguluyorum. Biraz da kullanımdan örnek verirsem daha iyi olacak sanırım..

Öncelikle kodu kendi yerelimde dallandırıyorum:

bzr branch http://code.raptiye.org/raptiye/main/ raptiye

Daha sonra bir takım değişiklikler yapıp yaptıklarımı gözden geçirmek için şu komutu veriyorum:

bzr diff|vi -

bzr diff komutu yaptıklarımın son revizyon ile farkını gösterirken "|vi -" komutu ise çıktıyı VI adlı editöre yönlendirir. Bu şekilde yaptıklarımı renkli ve daha okunabilir olarak izleyebiliyorum.

Yaptıklarımdan memnun kaldım ve teslim etmek istiyorum:

bzr ci

ci komutu commit komutunun kısaltması bu arada.. Bu komut sayesinde orjinal kodun kendi yerelimdeki dalında ilk teslimatımı yapmış oldum. Bu değişiklikleri ana sunucuya atmak istersem:

bzr push

komutunu kullanmalıyım. Bu komutu ilk kez kullanıyorsanız kodun yükleneceği yeri de belirtmelisiniz:

bzr push sftp://user@domain.com/home/code/raptiye/main/

Bu noktada önemli bir konuya değinmekte de fayda var. Performans kaynaklı sebeplerden dolayı bzr push komutu uzaktaki sunucunun yalnızca tarihçesini günceller ancak kod üzerinde gerekli olan değişiklikleri yapmaz. Bu değişiklikleri yapmak için sunucu üzerindeki kod tabanında bzr up komutunu çağırmalı ya da bunu sizin için yapan bir eklentiyi indirip yerelinize kurmalısınız.

Proje üzerinde birden fazla kişi çalıştığında sunucu üzerinde her geliştirici için bir hesap açmak istemeyebilirsiniz. Bu durumda ağ sunucusunda http protokolü üzerinden belli kişilere erişim izinleri tanımlayarak teslimat yaptırabilirsiniz. nginx üzerinde webdav yerine wsgi ayağı kullanılıyor ancak wsgi, nginx'in geliştirilme hızına yetişemediğinden ben çalıştırmayı beceremedim. (nginx'i, wsgi desteğiyle derlemekten bahsediyorum -- wsgi tarafında yamalar var ama onlar bile eski..)

Bundan sonraki projelerde Bazaar benim sürüm yönetimi için tercih etmeye devam ettiğim yazılım olacak. Eminim benimkini kolaylaştırdığı gibi sizlerin de hayatını kolaylaştıracaktır.