Subversion depolarında “şube”, “etiket” ve “gövde” ne anlama geliyor?

Subversion (ve sanırım genel depo) tartışmalarında bu kelimeleri çok gördüm. Son birkaç yıldır projelerim için SVN
kullanıyorum , ancak bu dizinlerin konseptini hiçbir zaman anlamadım.

Ne demek istiyorlar?

Hmm, Nick re etiketinin bir şubeye benzediğine katıldığımdan emin değilim. Etiket yalnızca bir işaretleyicidir

• Gövde , projenin başlangıcından bugüne kadar gelişen ana gelişme organı olacaktır.

• Şube , bagajdaki kodun bütünlüğünü korurken, koda büyük değişiklikler uygulamak için kullanılan bagajdaki belirli bir noktadan türetilen bir kod kopyası olacaktır. Büyük değişiklikler plana göre işe yarıyorsa, genellikle bagajda birleştirilirler.

• Etiket , gövdede veya korumak istediğiniz bir dalda zaman içinde bir nokta olacaktır. Korumanın iki ana nedeni, ya alfa, beta, RC ya da RTM olsun, yazılımın büyük bir sürümü olması ya da bu, bagajda büyük revizyonlar uygulanmadan önce yazılımın en kararlı noktası olmasıdır.

Açık kaynaklı projelerde, proje paydaşları tarafından bagajda kabul edilmeyen büyük dallar çatalların temeli olabilir - örneğin, ortak bir kaynağı diğer kaynak kodlarıyla paylaşan tamamen ayrı projeler.

Şube ve etiket alt ağaçları, bagajdan aşağıdaki şekillerde ayrılır:

Subversion, sistem yöneticilerinin belirli olaylar meydana geldiğinde yürütme için tetiklenen kanca komut dosyaları oluşturmasına izin verir ; örneğin, depoda bir değişiklik yapmak. Tipik bir Subversion veri havuzu uygulamasının "/ tag /" içeren herhangi bir yolu oluşturma işleminden sonra yazma korumalı olarak işlemesi çok yaygındır; net sonuç, etiketler oluşturulduktan sonra değiştirilemez (en azından "sıradan" kullanıcılara). Bu, etiket değiştirilen nesnenin üst düğümü ise başka değişiklikleri önleyerek değişmezliği zorlayan kanca komut dosyaları aracılığıyla yapılır .

Bir kendini sorumlu değişiklikler böylece Subversion'ın da "dal birleştirme izleme" ile ilgili, sürüm 1.5 beri özellikler eklemiş dalı birleştirilmiş artımlı desteği ile gövde içine geri, birleştirme "akıllı" olabilir.

Her şeyden önce, @AndrewFinnell ve @KenLiu'nun belirttiği gibi, SVN'de dizin adlarının kendileri hiçbir şey ifade etmiyor - "gövde, dallar ve etiketler" çoğu depo tarafından kullanılan ortak bir kongre. Tüm projeler tüm dizinleri kullanmaz ("etiketleri" kullanmamak oldukça yaygındır) ve aslında, hiçbir şey sizi istediğiniz her şeyi çağırmaktan alıkoymaz, ancak kuralların kırılması genellikle kafa karıştırıcıdır.

Muhtemelen şube ve etiketlerin en yaygın kullanım senaryosunu anlatacağım ve nasıl kullanıldıklarına dair örnek bir senaryo vereceğim.

• Gövde : Ana gelişme alanı. Bu, kodun bir sonraki büyük sürümünün yaşadığı ve genellikle en yeni özelliklere sahip olduğu yerdir.

• Şubeler : Her ana sürümü yayınladığınızda, bir şube oluşturulur. Bu, en yeni - muhtemelen tamamlanmamış veya denenmemiş - özellikleri serbest bırakmak zorunda kalmadan hata düzeltmeleri yapmanıza ve yeni bir sürüm yapmanıza olanak tanır.

• Etiketler : Her sürümü (son sürüm, sürüm adayları (RC) ve betalar) her yayınladığınızda bunun için bir etiket oluşturursunuz. Bu, kodun o durumda olduğu gibi anında bir kopyasını verir ve geçmiş bir sürümde gerekirse geri dönüp herhangi bir hatayı yeniden oluşturmanıza veya geçmiş bir sürümü olduğu gibi yeniden yayınlamanıza olanak tanır. SVN'deki dallar ve etiketler hafiftir - sunucuda, dosyaların tam bir kopyasını oluşturmaz, sadece birkaç bayt alan "bu revizyonda bu dosyalar kopyalandı" yazan bir işaretçi. Bunu göz önünde bulundurarak, asla yayınlanan kodlar için bir etiket oluşturma konusunda endişelenmemelisiniz. Daha önce söylediğim gibi, etiketler genellikle atlanır ve bunun yerine, bir değişiklik günlüğü veya başka bir belge, bir sürüm yapıldığında revizyon numarasını netleştirir.

Diyelim ki yeni bir proje başlattınız. Sonunda sürüm 1.0 olarak yayımlanacak olan "gövde" çalışmaya başlar.

• trunk / - geliştirme sürümü, yakında 1.0
• şube / - boş

1.0.0 bittikten sonra, yeni bir "1.0" dalına gövde dal ve bir "1.0.0" etiketi oluşturun. Şimdi nihayet 1.1 olacak üzerinde çalışmak bagajda devam ediyor.

• trunk / - geliştirme sürümü, yakında 1.1
• şubeleri / 1.0 - 1.0.0 sürümü
• tags / 1.0.0 - 1.0.0 yayın sürümü

Koddaki bazı hatalarla karşılaşırsınız ve bunları gövdeye sabitlersiniz ve sonra düzeltmeleri 1.0 dalına birleştirirsiniz. Ayrıca tersini yapabilir ve 1.0 dalındaki hataları düzeltebilir ve daha sonra bunları gövdeye geri birleştirebilirsiniz, ancak genellikle projeler bir şeyi eksik şansını azaltmak için tek yönlü birleştirme ile yapışır. Bazen bir hata yalnızca 1.0'da düzeltilebilir, çünkü 1.1'de kullanılmaz. Gerçekten önemli değil: Sadece 1.0'da düzeltilen hatalarla 1.1'i yayınlamadığınızdan emin olmak istiyorsunuz.

• trunk / - geliştirme sürümü, yakında 1.1
• şubeleri / 1.0 - yaklaşan 1.0.1 sürümü
• tags / 1.0.0 - 1.0.0 yayın sürümü

Yeterli hata (veya belki de bir kritik hata) bulduğunuzda, 1.0.1 sürümü yapmaya karar verirsiniz. Böylece 1.0 dalından "1.0.1" etiketi yapar ve kodu serbest bırakırsınız. Bu noktada, gövde 1.1 olacak ve "1.0" dalı 1.0.1 kodu içerir. Bir sonraki 1.0 güncellemesini yayınladığınızda, 1.0.2 olacaktır.

• trunk / - geliştirme sürümü, yakında 1.1
• şubeleri / 1.0 - yaklaşan 1.0.2 sürümü
• tags / 1.0.0 - 1.0.0 yayın sürümü
• tags / 1.0.1 - 1.0.1 sürüm sürümü

Sonunda 1.1 sürümüne neredeyse hazırsınız, ancak önce bir beta yapmak istiyorsunuz. Bu durumda, büyük olasılıkla bir "1.1" dalı ve "1.1beta1" etiketi yaparsınız. Şimdi, gövde üzerinde 1.2 (veya 2.0) olacak olan işler devam ediyor, ancak 1.1 üzerindeki çalışma "1.1" dalında devam ediyor.

• trunk / - geliştirme sürümü, yakında 1.2 olacak
• şubeleri / 1.0 - yaklaşan 1.0.2 sürümü
• şubeleri / 1.1 - gelecek 1.1.0 sürümü
• tags / 1.0.0 - 1.0.0 yayın sürümü
• tags / 1.0.1 - 1.0.1 sürüm sürümü
• tags / 1.1beta1 - 1.1 beta 1 sürüm sürümü

1.1 finali yayınladıktan sonra, "1.1" dalından bir "1.1" etiketi yaparsınız.

Ayrıca, üç dalın (1.0, 1.1 ve gövde) arasındaki hata düzeltmelerini de taşımak isterseniz, 1.0'ı korumaya devam edebilirsiniz. Önemli paket, bakımını yaptığınız yazılımın her ana sürümü için, söz konusu sürümün en son kod sürümünü içeren bir şubeniz olmasıdır.

Dalların bir başka kullanımı özellikler içindir. Burası, gövdeyi (veya sürüm şubelerinizden birini) şubeye bıraktığınız ve yeni bir özellik üzerinde ayrı ayrı çalıştığınız yerdir. Özellik tamamlandığında, yeniden birleştirir ve dalı kaldırırsınız.

• trunk / - geliştirme sürümü, yakında 1.2 olacak
• şubeleri / 1.1 - gelecek 1.1.0 sürümü
• branşlar / ui-yeniden yazma - deneysel özellik dalı

Bunun fikri, yıkıcı bir şey (diğer insanların işlerini yapmasını engelleyecek veya bunlara müdahale edecek), deneysel bir şey (hatta başaramayabilir) veya muhtemelen sadece uzun zaman alan bir şey üzerinde çalışırken (ve gövdeden 1.2 dallamaya hazır olduğunuzda 1.2 sürümü tutuyorsa korkarsınız), dalda ayrı olarak yapabilirsiniz. Genellikle, değişiklikleri her zaman birleştirerek gövdeyle güncel tutarsınız, bu da işiniz bittiğinde yeniden entegre edilmeyi (gövdeye geri birleştirmeyi) kolaylaştırır.

Ayrıca, burada kullandığım versiyonlama şemasının pek çoğundan sadece biri olduğunu unutmayın. Bazı ekipler hata düzeltme / bakım sürümlerini 1.1, 1.2, vb. Ve büyük değişiklikler 1.x, 2.x vb. Olarak yapar. Buradaki kullanım aynıdır, ancak dalı "1" veya "1 olarak adlandırabilirsiniz. "1.0" veya "1.0.x" yerine .x ". (Bir yana, anlamsal sürüm oluşturma , sürüm numaralarının nasıl yapılacağı konusunda iyi bir kılavuzdur).

Nick'in söylediklerine ek olarak Streamed Lines: Paralel Yazılım Geliştirme için Dallanma Desenleri hakkında daha fazla bilgi edinebilirsiniz

Bu şekilde maingövde, rel1-maintbir dal ve 1.0bir etikettir.

Genel olarak (takım agnostik görünümü), dal paralel gelişim için kullanılan mekanizmadır. Bir SCM'nin 0 ila n dalı olabilir. Subversion 0 var.

• Gövde , Subversion tarafından önerilen ana daldır , ancak hiçbir şekilde onu oluşturmak zorunda kalmazsınız. Buna 'ana' veya 'sürümler' diyebilir veya hiç birine sahip olamazsınız!

• Şube bir geliştirme çabasını temsil eder. Asla bir kaynaktan ('vonc_branch' gibi) sonra değil

  • 'myProject_dev' veya 'myProject_Merge' amacı
  • 'myProjetc1.0_dev' veya myProject2.3_Merge 'veya' myProject6..2_Patch1 'yayın sürümü ...

• Etiket , bu duruma kolayca geri dönmek için dosyaların anlık görüntüsüdür. Sorun, Subversion'da etiket ve dalın aynı olmasıdır . Ve kesinlikle paranoyak yaklaşımı tavsiye ederim:

  herkesin etiketler alanında yeni kopyalar oluşturmaktan başka bir şey yapmasını önlemek için Subversion ile sağlanan erişim denetimi komut dosyalarından birini kullanabilirsiniz.

Bir etiket kesindir. İçeriği asla değişmemelidir. ASLA. Hiç. Sürüm notunda bir satır mı unuttun? Yeni bir etiket oluşturun. Eskisini kaldırın veya kaldırın.

Şimdi, "böyle ve böyle dallarda, sonra da gövde dalında birleşmek" hakkında çok şey okudum. Buna birleştirme iş akışı denir ve burada zorunlu bir şey yoktur . Bir gövde dalınız olduğu için bir şeyleri birleştirmeniz gerekmez .

Kural olarak, gövde dalı gelişiminizin mevcut durumunu temsil edebilir, ancak bu basit bir sıralı proje için, bu aşağıdakileri içeren bir projedir:

• 'önceden' gelişme yok (mevcut 'gövde' geliştirme ile uyumlu olmadıklarını ima eden bir sonraki sürümü versiyon için)
• büyük yeniden düzenleme yok (yeni bir teknik seçimi test etmek için)
• önceki sürümün uzun süreli bakımı yok

Çünkü bu senaryonun biriyle (veya hepsiyle), kendinize dört 'gövde', dört 'mevcut gelişme' elde edersiniz ve bu paralel gelişmede yaptığınız her şeyin mutlaka 'bagajda' birleştirilmesi gerekmez.

SVN'de bir etiket ve dal gerçekten benzer.

Tag = zaman içinde tanımlanmış bir dilim, genellikle sürümler için kullanılır

Branch = ayrıca, geliştirmenin devam edebileceği zaman tanımlanmış bir dilim, genellikle 1.0, 1.5, 2.0 vb. Bu, bagajdaki değişikliklerle ilerlerken bir üretim sürümünü desteklemeye devam etmenizi sağlar

Gövde = geliştirme çalışma alanı, tüm gelişimin gerçekleşmesi gereken yer burası ve daha sonra değişiklikler şube sürümlerinden bir araya getirildi.

Gerçekten resmi bir anlamı yok. Klasör, SVN'nin oluşturduğu bir klasördür. Projenizi organize etmenin genel olarak kabul edilen bir yoludur.

• Gövde developmemt ana hattını tutmak yerdir. Şube klasörü, kısa bir gönderide açıklanması zor olan şubeler oluşturabileceğiniz yerdir.

• Şube, projenizden ayrı olarak üzerinde çalıştığınız alt kümenin bir kopyasıdır. Belki hiçbir yere gitmeyebilecek deneyler içindir, ya da belki bir sonraki sürüm için, daha sonra stabil hale geldiğinde bagajda tekrar birleşeceksiniz.

• Tags klasörü, genellikle sürüm kontrol noktalarında, deponuzun etiketli kopyalarını oluşturmak içindir.

Ama dediğim gibi, SVN için bir klasör bir klasördür. branch, trunkve tag sadece bir kongre.

'Kopyala' kelimesini liberal olarak kullanıyorum. SVN aslında depodaki şeylerin tam kopyalarını yapmaz.

Gövde son kaynak kodunu ve özelliklerini tutan gelişme çizgisidir. En son hata düzeltmelerinin yanı sıra projeye eklenen en son özelliklere sahip olmalıdır.

Dalları genellikle aksi olurdu gövde (ya da diğer gelişim çizgisi) bir şeyler uzakta yapmak için kullanılır kırmak yapı. Yeni özellikler genellikle bir dalda inşa edilir ve daha sonra bagajda birleştirilir. Dallar genellikle dallandığı geliştirme hattı için onaylanması gerekmeyen kodlar içerir. Örneğin, bir programcı bir daldaki bir şey üzerinde bir optimizasyon deneyebilir ve yalnızca optimizasyon tatmin edici olduğunda geliştirme hattında birleşebilir.

Etiketler belirli bir zamanda depo görüntüleridir. Bunlar üzerinde gelişme olmamalıdır. Genellikle bir istemciye yayımlanan öğelerin bir kopyasını almak için kullanılır, böylece bir istemcinin kullandığı öğeye kolayca erişebilirsiniz.

İşte depolar için çok iyi bir rehberin bağlantısı:

• Kaynak Kontrolü NASIL

Wikipedia'daki makaleler de okumaya değer.

Şimdi yazılım geliştirme ile ilgili bir şey var, hiçbir şey hakkında tutarlı bir bilgi yok, herkes kendi yoluna sahip gibi görünüyor, ancak bunun nedeni zaten nispeten genç bir disiplindir.

İşte benim basit basit yolum,

trunk - trunk dizini en güncel, onaylanmış ve birleştirilmiş iş gövdesini içerir. Birçoğunun itiraf ettiğinin aksine, bagajım sadece temiz, düzenli, onaylanmış işler için değil, bir geliştirme alanı değil, bir serbest bırakma alanı.

Bagajın serbest bırakılmaya hazır olduğu belirli bir noktada, o zaman etiketlenir ve serbest bırakılır.

branşlar - branşlar dizini deneyleri ve devam eden çalışmaları içerir. Şube altında çalışma, bagajda birleştirilmesi onaylanana kadar orada kalır. Benim için bu, tüm işlerin yapıldığı alandır.

Örneğin: Üründe beşinci bir geliştirme turu için bir yineleme-5 dalı, dokuzuncu bir deney turu için bir prototip-9 dalı ve benzeri olabilir.

tags - tags dizini, onaylanan dalların ve gövde sürümlerinin anlık görüntülerini içerir. Bir dalın bagajda birleşmesi onaylandığında veya bagajda bir serbest bırakma yapıldığında, etiketler altında onaylanmış dalın veya bagajın serbest bırakılması bir anlık görüntü yapılır.

Sanırım etiketlerle zaman zaman ileri geri atlayabiliyorum.

Ben bir web sitesi ararken SVN ilgili bu büyük öğretici buldum yazar arasında OpenCV Cookbook Programlama 2 Bilgisayar Görme Uygulama ve ben paylaşmak gerektiğini düşündüm.

SVN'nin nasıl kullanılacağı ve 'gövde', 'etiket' ve 'şube' ifadelerinin ne anlama geldiğiyle ilgili bir öğretici vardır.

Doğrudan eğitiminden alıntı:

Yazılım projenizin şu anda ekibinizin üzerinde çalıştığı geçerli sürümü genellikle trunk adlı bir dizinin altında bulunur . Proje geliştikçe, geliştirici bu düzeltme hatalarını günceller, yeni özellikler ekler) ve değişikliklerini bu dizin altında gönderir.

Herhangi bir zamanda, bir sürümü dondurmak ve yazılımın geliştirmenin bu aşamasında olduğu gibi bir anlık görüntüsünü yakalamak isteyebilirsiniz. Bu genellikle yazılımınızın resmi sürümlerine, örneğin müşterilerinize teslim edeceğiniz sürümlere karşılık gelir. Bu anlık görüntüler, projenizin etiketler dizininin altında bulunur .

Son olarak, bir noktada yazılımınız için yeni bir geliştirme çizgisi oluşturmak genellikle yararlıdır. Bu, örneğin, yazılımınızı değiştirmeniz gereken alternatif bir uygulamayı test etmek istediğinizde, ancak yeni çözümü kabul edip etmediğinize karar verene kadar bu değişiklikleri ana projeye göndermek istemediğinizde olur. Daha sonra ana ekip proje üzerinde çalışmaya devam ederken diğer geliştirici prototip üzerinde çalışabilir. Projenin bu yeni geliştirme hatlarını şubeler adlı bir dizinin altına koyacaksınız .

Trunk dizini, en son bildiğiniz dizindir, çünkü en son değişiklikleri tutmak için kullanılır. Ana kod tabanınız bagajda olmalıdır.

Şubeler dizini, her ne olursa olsun şubelerinizi tutmak içindir.

Tags dizini temel olarak belirli bir dosya kümesini etiketlemek içindir. Bunu, sürümlerde "1.0" bu revizyonlarda bu dosyalar ve "1.1" bu revizyonlarda bu dosyalar olmasını istediğiniz şeyler için yaparsınız. Etiketleri oluşturulduktan sonra genellikle değiştirmezsiniz. Etiketler hakkında daha fazla bilgi için, Bölüm 4'e bakın . Dallanma ve Birleştirme ( Subversion ile Sürüm Denetimi'nde ).

Herkesin biraz farklı bir tanımlamaya sahip olmasının nedenlerinden biri, Subversion'ın dallar ve etiketler için sıfır destek uygulamasıdır . Subversion temel olarak şöyle diyor: Diğer sistemlerde tam özellikli dallara ve etiketlere baktık ve bunları kullanışlı bulmadık, bu yüzden hiçbir şey uygulamadık. Bunun yerine , ad kuralına sahip yeni bir dizine kopyalayın . O zaman elbette herkes biraz farklı sözleşmelere sahip olmakta özgürdür. Gerçek bir etiket ile salt kopya + adlandırma kuralı arasındaki farkı anlamak için Wikipedia Subversion etiketleri ve dalları girişine bakın .

Tag = zaman içinde tanımlanmış bir dilim, genellikle sürümler için kullanılır

Bence bu "tag" ile tipik olarak ne anlama geliyor. Ama yıkımda:

Gerçekten resmi bir anlamı yok. Klasör, SVN'nin oluşturduğu bir klasördür.

ki oldukça kafa karıştırıcı buldum: dallar veya etiketler hakkında hiçbir şey bilmeyen bir revizyon kontrol sistemi. Uygulama açısından bakıldığında, Subversion'un "kopyalar" yaratmanın çok zekice olduğunu düşünüyorum, ama bunun hakkında bilmek zorundayım ki sızdıran soyutlama dediğim şey bu .

Ya da belki de CVS'yi çok uzun zamandır kullanıyorum.

Bazı karışıklıkların etiket kavramı ile SVN'deki uygulama arasındaki farktan kaynaklandığını düşünüyorum. SVN için etiket, kopya olan bir daldır. Etiketleri değiştirmek yanlış kabul edilir ve aslında yoldaki ../tags/ .. ile herhangi bir şeyi değiştirmeye çalışırsanız TortoiseSVN gibi araçlar sizi uyaracaktır.

'Etiket'in ne olduğundan gerçekten emin değilim, ancak şube oldukça yaygın bir kaynak kontrol konseptidir.

Temel olarak, dal gövdeyi etkilemeden koddaki değişiklikler üzerinde çalışmanın bir yoludur. Diyelim ki oldukça karmaşık yeni bir özellik eklemek istiyorsunuz. Değişiklikleri yaptığınız sırada kontrol edebilmek istiyorsunuz, ancak bu özelliği tamamlayana kadar gövdeyi etkilemesini istemiyorsunuz.

İlk önce bir şube yaratırsınız. Bu temelde dalı yaptığınız andan itibaren bagajın bir kopyasıdır. Daha sonra tüm işinizi şubede yaparsınız. Dalda yapılan değişiklikler gövdeyi etkilemez, bu nedenle gövde hala kullanılabilir, böylece başkalarının orada çalışmaya devam etmesine izin verir (hata düzeltmeleri veya küçük geliştirmeler gibi). Özelliğiniz bittikten sonra şubeyi tekrar gövdeye entegre edersiniz. Bu, tüm değişikliklerinizi şubeden gövdeye taşır.

İnsanların dallar için kullandıkları birkaç desen vardır. Aynı anda birden fazla ana sürümün desteklendiği bir ürününüz varsa, genellikle her sürüm bir şube olur. Çalıştığım yerde bir KG şubemiz ve bir Üretim şubemiz var. Kodumuzu KG'ye göndermeden önce KG şubesine değişiklikleri entegre ettikten sonra oradan konuşlandırıyoruz. Üretime izin verirken KG şubesinden Üretim şubesine entegre oluruz, bu nedenle üretimde çalışan kodun KG testinin test ettiği ile aynı olduğunu biliyoruz.

İşte şubelere Wikipedia girişi , çünkü muhtemelen benden daha iyi şeyler açıklıyorlar. :)

Gövde : Çevik olarak her sprint tamamlandıktan sonra kısmen sevk edilebilir bir ürünle çıkıyoruz. Bu sürümler bagajda tutulur.

Şubeler : Devam eden her sprint için tüm paralel geliştirme kodları şubelerde tutulur.

Etiketler : Kısmen sevk edilebilen bir ürün beta sürümü her yayınladığımızda bunun için bir etiket yaparız. Bu bize o sırada mevcut olan kodu verir, geliştirme sırasında bir noktada gerekirse bu duruma geri dönmemizi sağlar.

GIT'e aşina olan insanlar için, GIT'deki usta SVN'deki gövdeye eşdeğerdir.

Şube ve etiket, hem GIT hem de SVN'de aynı terminolojiye sahiptir.