SVN için bir sürüm kontrol stratejisi geliyor


9

24 saat şirketim için sürüm kontrolü için bir strateji geliştirmeye çalışacağım; şu anda SVN kullanıyoruz ama bunun bir yapısı yok - temelde sadece bir bagajımız var ve sadece buna bağlıyız. Son zamanlarda geliştirme yöneticisi, "etiketimiz" olarak işlev gören ikinci bir deposu başlattı, ancak aynı deponun bir parçası değil, tamamen ayrı bir havuz olduğu için "gövde" ile manuel olarak birleştirilmesi gerekiyor. Aslında, "Dev" (yalnızca farklı klasörlerde farklı "Dev" klasörleri var ama sadece "Dev" ana klasör) olarak adlandırılan tek bir klasör var ve bunun altında her şey var; diğer tüm projeler. Proje tarafından organize edilmemiştir, şube / etiket / gövde veya herhangi bir şey kavramı yoktur. Başlangıçta kuran kişi (çoktan gitti, Elbette) SVN'yi nasıl kuracağınızı bilmiyor gibiydi ve o zamandan beri kimse bir şeyleri kırma korkusu için işleri düzgün bir şekilde nasıl yapacağını öğrenmekle uğraşmadı. Herhangi bir CI (veya maalesef otomatik test) kullanmıyoruz.

İlk olarak, projeyle ayrılmalı mıyız? Örneğin: İki ASP.NET web sitesi (Web Uygulamaları değil, Web Siteleri değil), bir Web Hizmeti, tüm tablo komut dosyaları ve depolanmış yordamlar için bir dağıtım klasörü, harici projeler için çağrılan iki komut satırı istemcisi Web Siteleri ve ortak iş nesneleri ve benzerlerine sahip paylaşılan bir klasör. Bunların her biri bir şube / etiket / gövde kurulumuna sahip kendi projesi mi yoksa şu şekilde mi olmalı:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

ve tüm şubeler ve her şey Dev klasörünün bir kopyasına sahip mi? Bu yaklaşımın yutulması daha kolay olabilir, çünkü genellikle paylaşılan kod kütüphanesinde ve web sitelerinden en az birinde (genellikle ikisi de) değişiklikler yapmamız gereken durumlar vardır.

İkincisi, dev sunucumuza ve canlı sunucumuza düzenli olarak yayınlar yapıyoruz. Bunu ele almanın en iyi yolunu okuduğumdan, tüm gelişimin gövdeye girmesi / dalların "geçici" olması ve gövdeyi etkileyebilecek yeni bir özellik eklemek için kullanılması ve etiketler bültenler için mi? Diyelim ki her ay itiyoruz ve yepyeni bir modül üzerinde çalışıyorum. Ben şube şube ve kodumu yazmak ve test etmek ve ne olursa olsun bu dalı kullanın. Modül bittiğinde, onu tekrar gövdeye birleştiririm (ve belki şubeyi silebilirim) ve konuşlandırmaya hazır olduğumuzda etiketleyeceğiz ("May2011" diyelim). Yayına girdikten sonra bir hata düzeltmemiz varsa, May2011 etiketinde düzeltilip gövdeye birleştirilir (böylece gövde de düzeltmeyi alır), ve Mayıs2011 düzeltmeyle tekrar dışarı itilecekti? Bu etiketleme niyeti midir?


5
Kutu stratejisinin dışında: git'e geçin.
Rein Henrichs

Bu bir seçenek olsaydı, yapardım (veya bir Windows mağazası olduğumuz için Mercurial). Tamamen yeni bir kaynak kontrol sistemine geçmeye çalışırken en azından SVN ile düzgün bir ortam kurmaya çalışmaktan daha fazla dirençle karşılaşacağımı düşünüyorum.
Wayne Molina

2
DVCS konusunda heyecanlı olmama rağmen Subversion iyi bir araçtır. CVS veya klasör sürümü olmayan başka bir çözüm daha kötü olurdu.
Matthew Rodatus

2
@Wayne M - Aslında bunun tam tersi olduğunu görebilirsiniz. Bir DVCS kullanmanın tüm avantajlarını elde ederse, insanların daha makul bir çevre yapısına kaydolmalarını sağlamak daha kolay olabilir. Bir geçiş olarak, gitsvn veya hgsubversion kullanarak ucuz yerel dallanma / repo erişimini denemek için halk almayı düşünebilirsiniz. Bir kez takıldıktan ve araçlara alıştıktan sonra, birincil repo (lar) için bir DVCS'ye taşınmak için grup çapında bir arzu olabilir.
Mark Booth

Yanıtlar:


5

Birleştirilmiş bir oluşturma işlemi istiyorsanız, şubeleri / tags / trunk'u köküne aşağıdaki gibi koyduğunuzdan emin olun:

branches/
tags/
trunk/
  dev/
    ...

Birleştirilmiş bir derleme işlemine ihtiyacınız yoksa, isterseniz her bir projeye şubeler / etiketler / gövdeler koyabilirsiniz. Bununla birlikte, her bir projeye dahil ettikten sonra birleşik bir yapıya geçmek zor olabilir. Birleştirilmiş bir yapının, paylaşılan bileşenleri projeler arasında yayınlama ihtiyacını ortadan kaldırmak gibi avantajları vardır - hepsi yapının bir parçasıdır.

Şahsen, birleşik bir inşa sürecini seviyorum. Dahası, bir "dev" projeniz olması gerektiğini düşünmüyorum. Doğrudan gövde altında projeleriniz olmalı ve daha sonra gövdeyi bir dev dalına dönüştürmelisiniz. Sürümler için etiketleri kullanın. Örneğin, bunu şöyle yaparım:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1
Birleştirilmiş bir yapının, paylaşılan bileşenleri projeler arasında yayınlama ihtiyacını ortadan kaldırmak gibi avantajları vardır - hepsi yapının bir parçasıdır.
Matthew Rodatus

2
Birden fazla birleşik derlemeye ihtiyacınız varsa, her biri için bagajın altında dizinler oluşturun. Ancak, bir "dev" adını vermezdim - bu bir dalla daha iyi yapılır. Örneğin, biri aygıt sürücülerinde, diğeri şirket web sitesinde çalışan iki birincil geliştirici kuruluşunuz olabilir. Muhtemelen iki ayrı birleşik yapı istersiniz.
Matthew Rodatus

1
  1. Svn içindeki kod yapısı kadarıyla bu gerçekten kişisel bir seçimdir.

Projelerle ilgili veya paylaşma kodu varsa ortak bir gövde istediklerini öneririm. Eğer bağımsızlarsa ayrı gövdeler, hatta ayrı depolar isterler. Üçüncü bir tarafa bir proje için svn geçmişinin bir kopyasını sağlamanız gerekiyorsa, ayrı bir depoda olması çok daha kolaydır.

Yani sizin durumunuzda, yukarıda çizdiğiniz mizanpajın, kod paylaştığınızdan ve şubelerin / etiketlerin bu paylaşılan kodu içermesini istediğinizden makul olacağı anlaşılıyor.

  1. Etiket ve şube kullanımı açıklamanız son derece mantıklı geliyor ve svn'nin nasıl kullanılacağını bekliyorum. Gerçekten anladığım kadarıyla etiketlemenin niyeti budur. Svn etiketleri ve dallarındaki BTW aslında aynı şeydir, ancak terminoloji uyguladığınız gibi uygulanır.

Şahsen ayrıca, gövdeye adanmış herhangi bir şeyin inşa etmesi, atomik olması ve herhangi bir birim testini kırmaması gerektiği uyarısını da ekleyeceğim. Şubeler devam eden bitmemiş işler içindir. Bagajın herhangi bir noktada potansiyel bir serbest bırakma adayı olmasını beklerdim.


Sadece test edilmiş, üretime hazır kodun bagajda olması gerektiğini mi söylüyorsunuz? Ben taahhüt herhangi bir kod inşa ve muhtemelen testleri geçmek gerektiğini düşünüyorum ve gövde kodu elbette testleri geçmek gerekir. Ancak SVN'nin amacı, geliştirme geçmişini takip edebilmek gibi görünüyor ve birden fazla şubeye bölünmemişse bu daha kolay. Belki de gövde test edilmiş, üretime hazır durumda olduğunda gövdeyi birleştirdiğiniz bir dal olmalıdır?
Bay Jefferson

0

Bir Subversion deposu oluşturmanın en iyi yolu aşağıdadır

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

Bu şekilde bireysel projeleri kendiniz kontrol edebilirsiniz.

Tüm 3 projeleri kontrol etmek ve bazı monolitik yapı komut dosyası / sistem ile birleşik bir yapı yapmak istiyorsanız o zaman bir kullanma araştırmak usta ile modül svn: externals içine tüm diğer projeleri haritalama usta trunk .

Bu ilk bakışta daha karmaşıktır, ancak Subversion ile bu sorunu çözmenin en sürdürülebilir ve deyimsel yoludur.


2
Kesinlikle katılmıyorum. Depo sadece mağaza kodundan daha fazlasını yapar; organizasyon yapısını ve bileşenler arasındaki ilişkiyi iletir; örtülü de olsa hayati bir iletişim kanalıdır. Her bir projeyi ayrı ayrı keserseniz, iletişimde yapay ve gereksiz engeller ortaya çıkarırsınız.
William Payne
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.