İnsanoğlu okuma, yazmayı icat etmeden önce mağara duvarlarına resimler yaparak düşüncelerini şekillendirmeye başladı. Araştırmalara göre ilk yazının Sümer’liler tarafından İsa’dan önce 3500 civarında icat edildiği söylenmektedir. O devrin insanları yazı benzeri işaretler kullanarak ilk dokümanları oluşturmuş ve bu dokümanları iletişim aracı olarak kullanmışlardır. Günümüzde latin alfabesinde yer alan kelimeleri kullanarak bilgisayarda dijital dokümanlar oluşturuyoruz, arkadaşlarımıza email gönderiyoruz yada elimize kağıt ve kalem alarak mektup yazıyoruz. Bu işlemlerin sonucunda dijital olan yada olmayan bir doküman oluşuyor.
Her doküman oluşturulduğu ilk saniyeden itibaren bir versiyon ihtiva eder. Bir versiyon, dokümanın geleceğe doğru olan yolculuğunda durak yaptığı istasyonlardan birisidir. Zaman içinde doküman değişikliğe uğrar. Her değişikliğin ardından dokümanın yeni bir versiyonu oluşur. Dokümanın herhangi iki versiyonu arasındaki fark, bu iki versiyonun oluşumu için geçen zaman diliminde, doküman üzerinde yapılan tüm değişiklikleri ihtiva eder.
Bu yazıyı PDF olarak edinebilirsiniz.
Subversion ile Versiyon Kontrolü (483,2 KiB, 10.094 yükleme)
EOF (End of Fun)
Özcan Acar
ali serdar ilter
07 Nisan 2009Merhaba,
Burada branch’i trunk ile merge etme işleminin başarılı gerçekleşme yüzdesi nedir?
Örneğin mantıksal bir hata çok önceki bir tag’den branch etmemizi gerektirdi. Bu durumda trunk üzerinde ilgili tag’den bu yana yapılabilecek birçok değişiklik olabileceği aklıma geliyor. Mesela geçmiş tag’de mantıksal hatayı düzeltmek için branch oluşturarak değiştireceğimiz bir metodun class’ı şu anda trunk’ta mevcut olmayabilir veya vardır ama içindeki çoğu metod artık kullanılmıyor da olabilir. Bu gibi durumlarda nasıl merge olabiliyor. Sildiğimiz class ya da metodlar trunk’a geri mi geliyor?
Kolay gelsin
submersion
07 Nisan 2009Subversion yerine Linus Torvalds’in yazdigi Git sistemi daha iyi.
acar
10 Nisan 2009Branck ile trunk in merge edilmesi cok komplike bir bir hal alabilir. Bunu önlemek icin branch ile trunk in aralarinin cok fazla acilmamasina dikkat edilmelidir. Örnegin branch actiktan sonra 5 hafta sonra merge edilmesi hemen hemen imkansiz hale gelebilir, cünkü trunk devamli ilerler. Eger 2-3 gün akabinde merge edilirse, sorun cikmayacaktir. Cogu zaman branch icinde birkac sinifta meydana gelen degisiklikler trunk a alinir ve merge islemi gerceklesmis olur.
acar
10 Nisan 2009Iki sistem arasinda ne gibi farkliliklar var?
xert
10 Mayıs 2009Merhaba Özcan Bey,
Uzun zamandır geliştirdiğim web yazılımımın versiyon kontrolünü subversion ile yapmayı istiyorum. Şimdiye kadar belirli aralıklarla 1.0.0, 1.0.1 gibi artırarak devam ettim. Internet aramalarım sonucu subversion ve tortoise kurmuştum. Baya da uğraştırdı çözmek. Bu sayfayı ve pdf dökümanı daha önce görseydim sanırım baya zaman kazanırdım. Sanırım yerli olarak bu konuyu en iyi özetleyen kaynak bu baktıklarım arasında. O yüzden emeğinize sağlık. Soruma gelince:
Biraz da zaman darlığı nedeniyle dökümanları çok hızlı taramak zorunda kalıyorum. Anlamadığım nokta şu. Subversionda örneğin şu an revision 47. Sürümü 1.0.0 dan başlattım. ( bir yıldır yaptığım değişiklikleri karar veremediğim için yok saydım.). Peki ne zaman sürüm 1.0.1 yazmam gerekiyor. Atıyorum örneğin revisionlar her 100 arttığında bir arttırma mı yapacağım. Yani bu süreç bana mı kalıyor yine. svn sadece revisonu mu otomatik arttırıyor. Ayrıca yine 1.0.1 ne zaman 1.1.0 olacak. 1.0.99 dan sonra mı? Yani kafam karıştı özetle.
Ayrıca bazen bir dosyayı değiştirdiğimde yazılımın (ki hele webse) tüm mimarisini değiştirmiş olabiliyorum. Ama svn revisionu sadece 1 arttırıyor. Halbuki o değişiklik atıyorum 100 revisiona bedel. Ayrıca veritabanı değişiklikleri de var. Onları da svn görmüyor.
Sanırım kısa bir yanıtı yok sorduklarımın farkındayım lakin en azından zaman bulup dökümanları daha derinlemesine incelemeye fırsat buluncaya kadar versiyonlamaya da devam edebilmeyi istiyorum.
Teşekkürler.
acar
10 Mayıs 2009Genel olarak sunu belirtmek gerekir: Subversion bünyesindeki revizyon numarasi ile sürüm numarasi (release version number) arasinda dogrudan bir iliski yoktur. Lakin Subversion bünyesindeki revizyon numarasini bir sürüm numarasi ile iliskilendirebilirsiniz. Subversion yapilan degisikliklerin takip edilebilmesi icin global gecerli olan bir revizyon numarasi kullanmaktadir. Siz degisik revizyonlari kiyaslayarak, meydana gelen degisikleri görebilirsiniz.
Sürüm numarasi x.y.z (örn. 1.01.1) seklinde olabilir. x programlarda köklü degisiklikler meydana geldiginde degisir. y API degisiklikleri dedigimiz, alt versiyonlara uyumluluklarin ortadan kaldiginda artirilir. z ise hata temizlemesi (bugfixing) yaptiktan sonra artirilir. Bu (z) Subversion un revizyon numarasi ile kiyaslanabilir.
Sürüm yönetimi ve numaralandirilmasi tamamen sizin elinizde olan birsey ve Subversion tarafindan dolayli olarak desteklenir (etiketler olusturarak). Siz yeni bir sürüm olusturdugunuz zaman bu sürüme örnegin 2.1.0 sürüm numarasini verirsiniz ve kodlari Subversion bünyesinde bu label ile etiketlersiniz (tagging).
çağdaş
03 Eylül 2009Paylaşımınız için teşekür ederim.
Paylaşımınıza ek olarak, merak edenler için “Git” tutorial’ı bu adresten erişilebilir:
http://excess.org/article/2008/07/ogre-git-tutorial/
Ayrıca, Git’in yaratıcısı Linus Torvalds’ın Google’da düzenlediği (sanıyorum lansman) seminere de bu adresten ulaşılabilir :
http://www.youtube.com/watch?v=4XpnKHJAok8
Sevgiler (:
Cem
22 Aralık 2009Merhaba,
Çalıştığım firmada çalışma alışkanlıklarımıza ve development flowuna göre aslında subversion’ı tam tersinden uygulamak zorunda kaldık. Biraz GIT vari bir yapı oldu (herkes kendi assignmentına ait branch üzerinde geliştirmesini yapıyor, ardından haftada iki gün alfa ve beta trunklarına merge ediliyor, development ve release trunkları var ve bilinen son stable lar ve rc ler herhangi bir anda bu trunklarda bulunabilir vs…..) Tabii geliştirmeler her zaman 1-2 günde çıkmıyor yahut çok düşük bir priority ile geçmişte kalan fix edilmemiş buglar ya da regresyon testlerinde QA ekibinin gözden kaçırmış olduğu zerzevat merge işlemini gayet olumsuz etkiliyor. Örneğin daha dün iki takım arkadaşım öğleden sonralarını çok kritik bir feature branch i trunka merge etmek ve çıkan conflictleri çözmekle geçirdiler. Tabii trunk güncellenince devam eden developmentların sahipleri trunk ı kendi feature branchlerine merge etmek zorunda kaldılar :) Açıkçası burası biraz daha sancılıydı :).
Önemli olan aslında işi kurallarına bağlamak. 8 kişilik development ekibinde sadece 2 kişi trunk’a commit edebilir vaziyetteyiz, diğer arkadaşlar pre-commit hook tarafından bloke edilecek şekilde ayarlandı. Tabii ki herkes üzerinde çalıştığı assignmentın numara ve tipi ile birlikte en az 20 karakter log mesajı yollamak zorunda. Hatta alfa ve beta deploymentlarını da ilgili sunuculara sadece 2 kişi yapıyor, diğer arkadaşlara “cıss” ve tabii ki sunucudaki dosyalara elle müdahale, live daki sunucuların üzerindeki dosyalara manuel editleme, development ortamında dosyaları kopyala-yapıştır ile “yedeklemek” falan olduğu gibi tüm ekibi yemeğe çıkartmakla cezalandırılıyor ;). Bunlar aslında angarya gibi gelen ve kolay kabul edilmeyen fakat hayatımızı çok kolaylaştıran kurallar. Eskiden “Ya arkadaşlar bunu kim bu hale soktu” şeklinde ortaya haykırılan sorular artık kalmadı mesela ;) Ya da “Ya şu müşterideki revizyon kaçtı ne atmıştık biz bunlara?” gibi “sıkıntılar” artık yaşanmıyor. Eh aslında sadece bu kadarı bile bir “başarı hikayesi” olmaya yetti galiba :)
Emre
20 Şubat 2012Özcan bey merhabalar,
Öncelikle çalışmanız için çok teşekkür ederim şahsım adına. Yalnız, sayfadaki pdf dökümanı sanırım bozulmuş, boyutu 20 byte gözüküyor, zaten adobe de açamıyor bozuk diye. Rica etsem belgenin bozulmamış halini yeniden koyar mısınız siteye?
Çok teşekkürler, iyi günler.
Özcan Acar
20 Şubat 2012Ilgileniyorum.
selamlar