Bir SVN deposu mu yoksa çok mu?

Birden fazla ilgisiz projeniz varsa, bunları aynı depoya koymak iyi bir fikir mi?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

yoksa her biri için yeni depolar mı oluştururdunuz?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Her birinin artıları ve eksileri nelerdir? Şu anda düşünebildiğim tek şey, karışık revizyon numaraları elde ettiğiniz (yani ne?) Ve kullanamayacağınızsvn:externals depo aslında harici . (bence?)

Sormamın nedeni, SVN sunucum repo başına ücret almaya başladığından beri birden fazla depomu tek bir depoda birleştirmeyi düşünmemdir.

Tekli ve çoklu sorun, kişisel veya organizasyonel tercihe bağlıdır.

Çoklu ve tekli arasındaki yönetim, esas olarak erişim kontrolü ve bakıma bağlıdır.

Tek bir havuz için erişim kontrolü, tek bir dosyada bulunabilir; Birden çok depo, birden çok dosya gerektirebilir. Bakımın benzer sorunları vardır - bir büyük yedekleme veya çok sayıda küçük yedekleme.

Ben kendim yönetiyorum. Her biri kendi etiketleri, gövdesi ve dalları olan bir depo, birden fazla proje var. Biri çok büyürse veya bir müşterinin kodunu rahatlığı için fiziksel olarak izole etmem gerekirse, hızlı ve kolay bir şekilde yeni bir depo oluşturabilirim.

Yakın zamanda, çok sayıda kaynak kodu kontrol sisteminin Subversion'a taşınması konusunda nispeten büyük bir firmaya danıştım. Çok küçükten kurumsal uygulamalara ve kurumsal web sitelerine kadar ~ 50 projeleri var. Planları mı? Tek bir depoyla başlayın, gerekirse birden çok depoya geçin. Taşıma neredeyse tamamlanmıştır ve hala tek bir depodadır, tek bir depo olduğu için herhangi bir şikayet veya sorun bildirilmemiştir.

Bu ikili, siyah beyaz bir sorun değil.

Sizin için neyin işe yaradığını yapın - sizin konumunuzda olsaydım, komutları yazabildiğim kadar hızlı bir şekilde projeleri tek bir depoda birleştirirdim, çünkü maliyet (çok, çok küçük) şirketim için önemli bir faktör olurdu.

JFTR:

Subversion'daki revizyon numaralarının deponun dışında hiçbir anlamı yoktur. Bir revizyon için anlamlı adlara ihtiyacınız varsa bir TAG oluşturun

Commit mesajları, depodaki yola göre kolayca filtrelenir, bu nedenle yalnızca belirli bir projeyle ilgili olanları okumak önemsiz bir egzersizdir.

Düzenleme: SVN için tek bir yetkilendirme / kimlik doğrulama yapılandırması kullanmaya ilişkin ayrıntılar için Blade'in yanıtına bakın .

Özel durumunuz için bir (1) depo mükemmeldir. Çok para biriktireceksin. İnsanları her zaman tek bir depo kullanmaya teşvik ediyorum. Tek bir dosya sistemine benzer olduğu için: Daha kolay

• Kodu aradığınız tek bir yere sahip olacaksınız
• Tek bir yetkiniz olacak
• Tek bir commit numaranız olacak (hiç 3 depoya yayılan bir proje oluşturmayı denediniz mi?)
• Ortak kitaplıkları daha iyi yeniden kullanabilir ve bu kitaplıklardaki ilerlemenizi izleyebilirsiniz (svn: externals PITA'dır ve tüm sorunları çözmez)
• Tamamen farklı öğeler olarak planlanan projeler, birlikte büyüyebilir ve işlevleri ve arayüzleri paylaşabilir. Birden çok depoda bunu başarmak çok zor olacaktır.

Birden fazla depo için tek bir nokta vardır: büyük depoların yönetimi rahatsız edicidir. Büyük depoların boşaltılması / yüklenmesi çok zaman alır. Ancak herhangi bir idare yapmadığınız için endişeniz olmayacağını düşünüyorum;)

SVN, daha büyük depolarla çok iyi ölçeklenir, çok büyük (> 100GB) depolarda bile yavaşlama olmaz.

Böylece tek bir depo ile daha az uğraşacaksınız. Ama repo düzenini gerçekten düşünmelisiniz!

Birden çok depo kullanırdım. Kullanıcı erişim sorununa ek olarak, yedekleme ve geri yüklemeyi de kolaylaştırır. Ve kendinizi birisinin kodunuz (ve onun geçmişi) için size ödeme yapmak isteyeceği bir konumda bulursanız, onlara yalnızca bir depo dökümü vermek daha kolaydır.

Yalnızca barındırma sağlayıcınızın ücretlendirme politikaları nedeniyle depoları konsolide etmenin çok iyi bir neden olmadığını öneririm.

Tek bir depo kullanıyoruz. Tek endişem ölçek idi, ancak ASF'nin deposunu (700 bin revizyon ve sayım) gördükten sonra, performansın bir sorun olmayacağına oldukça ikna olmuştum.

Projelerimizin tümü, herhangi bir uygulama için bir dizi bağımlılık oluşturan birbiriyle ilişkili, farklı birbirine bağlı modüllerdir. Bu nedenle tek bir depo idealdir. Her proje için ayrı gövde / dallar / etiketler isteyebilirsiniz, ancak yine de tüm kod tabanınızda tek bir revizyonda atomik olarak bir değişiklik gerçekleştirebilirsiniz. Bu, yeniden düzenleme için harika.

Kararınızı verirken, birçok SVN deposunun aynı yapılandırma dosyasını paylaşabileceğini unutmayın.

Örnek (yukarıdaki bağlantıdan alınmıştır):

Kabukta:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Dosya: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Dosya: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Ayrı depolar oluşturacaktım ... Neden? Revizyon numaraları ve commit mesajları bir anlam ifade etmeyecek, eğer tek bir depoda çok sayıda ilgisiz projeniz varsa, kısa vadede kesinlikle büyük bir karmaşa olacaktır ...

Küçük bir yazılım şirketiyiz ve tüm geliştirmelerimiz için tek bir repo kullanıyoruz. Ağaç şuna benzer:

/client/<clientname>/<project>/<trunk, branches, tags>

Fikir, aynı depoda müşteri ve şirket içi çalışmamız olacaktı, ancak şirketimizi kendisinin bir "müşterisi" haline getirdik.

Bu bizim için gerçekten işe yaradı ve arayüz için Trac kullanıyoruz. Revizyon numaraları tüm repo genelindedir ve tek bir projeye özgü değildir, ancak bu bizi aşamalı hale getirmez.

Şahsen, her biri için yeni depolar yaratırdım. Teslim alma sürecini çok daha basit tutar ve en azından kullanıcı erişimi ve yedeklemeler açısından yönetimi tamamen kolaylaştırır. Ayrıca, global sürüm numarası sorununu ortadan kaldırır, bu nedenle sürüm numarası tüm projelerde anlamlıdır.

Gerçekten de git kullanmalısınız;)

Dikkate alınması gereken bir diğer husus, birden fazla depo kullanmanın, birleşik günlüğe (svn günlük komutu) sahip olma yeteneğini kaybetmenize neden olduğu gerçeğidir, bu tek başına tek bir depo seçmek için iyi bir neden olacaktır.

TortuiseSvn kullanıyorum ve "Günlüğü Göster" seçeneğinin zorunlu bir araç olduğunu buldum. projeleriniz ilgisiz olsa da, merkezi bir küresel çapraz projeler bilgisine (yollar, hata kimlikleri, mesajlar vb.) sahip olmanın her zaman yararlı olduğunu göreceksiniz.

SVN ile entegre olan trac gibi bir araç kullanmayı planlıyorsanız veya kullanıyorsanız, proje başına bir repo kullanmak daha mantıklıdır.

Blade'in dosya paylaşımı konusundaki önerisine benzer şekilde, burada biraz daha kolay, ancak daha az esnek bir çözüm var. Bizimkini şöyle kurarım:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

"Bin" de, boş bir depo oluşturmanın tüm kurulum işlerini yapacak svn-create.sh adında bir komut dosyası tutuyorum. Yedek komut dosyasını da orada tutuyorum.

"Repository_files" içinde, tüm depoların sym bağlarının olduğu ortak "conf" ve "hooks" dizinlerini tutuyorum. O zaman, yalnızca bir dosya grubu vardır. Bu, bağlantıları koparmadan proje başına parçalı erişime sahip olma yeteneğini ortadan kaldırır. Bunu kurduğum yerde bu bir endişe değildi.

Son olarak, svnroot'taki her şeyi görmezden gelerek / var / svn ana dizinini kaynak kontrolü altında tutuyorum. Bu şekilde depo dosyaları ve komut dosyaları da kaynak kontrolü altındadır.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Mlambie'nin tek bir depo kullanmasına benzer, ancak belirli proje türlerine kolayca yakınlaştırmak için klasör yapısında biraz daha ileri gitmiştir - web html tabanlı projeler, cs (C #) ve sql (SQL oluşturma / çalıştırma betikleri) ve xyz ( Afl (AmiBroker Formül Dili) veya ts (TradeStation)) gibi Etki Alanına Özgü Diller:

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Not, varsayılan dal olarak ele aldığım için şubeler içinde canlı gövde var. Bazen tek acı, hızlı bir şekilde başka bir proje oluşturmak istediğinizde, ProjeAdı / dallar | etiketler yapısını oluşturmanız gerekir. Uygulama ayarlarını basitçe, belirli Apps ayar dosyalarını depoda başkalarıyla kolayca paylaşılabilecek şekilde saklamak için bir yer olarak kullanıyorum (ve bu klasör yapısında ClientName yerine VendorName ve ProjectName'i AppName ile değiştiriyorum; ve dallar | etiketleri, farklı ana alanlardaki ayarları etiketlemek için yararlı olabilir satıcı ürünlerinin sürümleri de).

Yapımla ilgili herhangi bir yoruma hoş geldiniz - kısa süre önce bunu değiştirdim ve şimdiye kadar oldukça mutlu oldum, ancak bazen dalları korumak için külfetli buluyorum | proje başına yapıları etiketler - özellikle proje sadece Unit Test için başka bir proje için bir proje kurulumu ise.

Benim önerim bir. Her birine erişen farklı kullanıcılarınız yoksa, o zaman birden çok kullanın derim.

Ama yine de, bu bile çoklu kullanmak için iyi bir neden değil.