Re: CVS Önerisine İhtiyaç
* Murat Demirten <murat@debian.org> [2003-10-03 09:53:42+0300]
> Bu arada ben bir iki şey sormak istedim. Şahsen cvs'i beğeniyorum
> eksikleri var ayrı. Özellikle branch, tagleme, branch üzerinden branch
> vs. bir kere alışıldı mı kullanışlı. Subversion'da branch ve tag o
> anki dizin yapısının kopyalanmasından oluşuyor anladığım kadarıyla. Bu
> da çok yoğun bir projede binlerce dizin kopyası demek mi oluyor?
Guzel bir soru :-) Bak ben buna bir `Subversion' deyimiyle cevap
vereyim: "Subversion'da koypalar ucuzdur". Turkcesi tam uymadiysa
Ingilizcesi su: "Subversion copies are cheap". Neden ucuz? Cunku
svn'de olusturdugunuz kopyalar aslinda mevcut bir dizine isaret eder ve
sadece yapilan degisikliklerin `rysnc'daki deltalara benzer sekilde
saklanmasiyla ekstra bir alan kullanilmis olur. Linux'da `ln' komutuyla
olusturdugunuz hard-link'e benzer birsey bu. Dikkat edilecek olursa
-daha uygun bir tabir bulamadigimdan- "rsync delta"lari dedim, zira bu
format bildigimiz diff'den daha farkli ve binary/text ayirdetmiyor.
> Bir de asıl merak ettiğim locking mekanizması içi subversion'da bir
> çözüm var mı?
Bu `locking' konusunda sana cok iyi bir haber veremeyecegim. Benim
anladigim kadariyla Subversion'da *simdilik* CVS'deki
"copy-modify-merge" modelinin aynisi kullaniliyor. Neticede versiyon
kontrol'u programlarinin cozmekle mukellef oldugu en temel ve zorlu
problem budur. Saniyorum gelecek surumlerde belki yeni algoritmalar
icat edilebilir. Bu konuyu Subversion kitabinda cok nefis aciklamislar,
mutlaka bir goz atilmasini oneririm:
http://svnbook.red-bean.com/html-chunk/ch02s02.html
> Oldukça ümit vadeden bir proje, elemanlar ufak ayrıntılara dikkat
> ediyorlar. Mesela network trafiğini azaltmak için hem update hem
> commit işlemlerinde diff'ler gönderiliyor. Cvs'te sadece update diff
> üzerinden yapılıyor vb.
Subversion'in Apache2 ile birlikte harikalar yarattigini soylemeliyim.
Burada kritik terim Apache2'de kullanilmaya baslanan WebDAV/DeltaV
protokolu. Basitce tanimlamak gerekirse bu protokol -versiyon kontrolu
de yaparak- butun bir ag'i Apache2 uzerinden bir dosya sistemi gibi
kullanmanizi sagliyor. Dosyalarin lokal veya remote olarak kaydedilmesi
hususunda bir ayirim yapmiyor. Nasil bir yenilik ile karsi karsiya
oldugumuzun anlasilmasi icin bir ornek verecegim. Simdi asagida bir svn
deposuna (repository) ait bir bag veriyorum (subversion'in kendi kodu):
http://svn.collab.net/repos/svn/
Bu bagi, browserinizda acarak soyle bir dolasin etrafta bakalim :-)
`trunk' dizininde gordukleriniz svn'e konulmus subversion kodunun son
hali ve bunu gostermek icin baglandiginiz sunucu Apache2 + svn modulu
disinda ozel hicbir sey kullanmiyor. Tabii depoyu daha ayrintili gormek
isterseniz is baska. Bu is icin "subversion"i da destekleyen `viewcvs'i
kullanacaksiniz.
Yeri gelmisken bu dizin yapisinin yani `trunk/branches/tags'in ne
olduguna degineyim. Version kontrolu -guvenlik konusunda oldugu gibi-
bir dizi calisma disiplini/aliskanliklari gerektirir. Yani gelistirme
modeliyle ilgili kafanizda olusmus bir model yoksa `svn' veya `cvs'den
harikalar yaratmasini beklemeyin. Dallanmalardan sonra, sira
birlestirmeye (merge) geldiginde olusacak conflict'leri siz
cozeceksiniz, `svn' bunu otomatik olarak cozemez ;-) Iste bahse konu
dizin yapilari bu gelistirme modeliyle alakali. Herseyden once sunu
belirteyim. Bu dizin isimlendirmeleri ve hiyerarsisi `subversion'in
dikte ettirdigi veya subversion kodunda dikkate alinan seyler degil.
Ilk olarak Subversion kitabinda onerilen -dikkat sadece bir oneri- bu
dizinler isinizi olaganustu derecede kolaylastiriyor ve disiplinize
ediyor. [1] Mesela soyle bir proje deposu:
proje/
|
------->
trunk/
branches/
tags/
* `trunk': Guncel ve kararli olan "mainstream" proje kodu burada.
Gelistiriciler dogrudan bu dizin uzerinde calisarak commit
yapabilirler. Fakat yapilacak degisiklikler buyuk capta ise `trunk'in
bir kopyasi `branches'a alinarak orada calisilir ve daha sonra tekrar
`trunk'a merge edilir.
* `branches': Cesitli sebeplerle `trunk'dan yapilan butun dallanmalar
burada. Mesela burada projenin `unstable' hali gelistirilebilir.
Veya `tags' altinda release ettiginiz bir kodun bugfixleri de ilgili
`branch'da yapilir.
* `tags': Diyelimki `trunk'daki kod artik yeterince stabilize oldu ve
dagitimina (release) karar verdiniz. Bu is CVS'de mevcut kodu
tag'leyerek oluyordu. Subversion'da *tag* diye ozel bir sey *yoktur*!
Fakat sizin bir dizine verdiginiz ozel bir anlam vardir. Dagitimina
karar verdiginiz kodun `trunk'taki halini `tags' dizini altina
kopyaliyorsunuz (`tags/v1.2.0' gibi). Yani `tags' dizini altindaki
dizinler siz ona bu anlami verdiginizden dolayi -trunk veya
branches'dan farkli olarak- zaman icerisinde *degismez*. Dagitimi
yapilan v1.2.0'a ait buglar soz konusu ise o da basit. Once
`tags/v1.2.0' dizininin bir kopyasini misal `branches/1.2.1' olarak
olusturuyorsunuz. Ilgili duzeltmeleri yaptiktan sonra v1.2.1'i commit
edip `tags/1.2.1'e kopyaliyorsunuz. Tabii bu degisiklikleri trunk'a
tasimak icin de `branches/v.1.2.1' ile `trunk'i *merge* ediyorsunuz.
Umarim bu bilgiler `subversion' hakkinda yeteli bir on fikir vermistir.
[1] `trunk/branches/tags' yapisiyla calismak icin `Joey Hess'in yazdigi
kucuk ve mukemmel bir script var: `svnpath'. Ben bu betigi cok sik
kullaniyorum. Kendisiyle yaptigim gorusmelerde bu betigi esas alan bir
dizi yardimci betik daha hazirladik. Ilgilenenler bu betiklere
asagidaki `viewcvs' deposundan ulasabilirler:
http://cvs.kitenet.net/trunk/bin/?root=joey
--
roktas
Reply to: