Uno o molti repository SVN?

Se hai più progetti non correlati, è una buona idea metterli nello stesso repository?

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

o creeresti nuovi repository per ciascuno?

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

Quali sono i pro ed i contro di ognuno? Tutto ciò a cui posso pensare attualmente è che ottieni numeri di revisione misti (e allora?) E che non puoi usare a svn:externalsmeno che il repository non sia effettivamente esterno. (penso?)

Il motivo per cui lo chiedo è perché sto considerando di consolidare i miei repository multipli in uno solo, dal momento che il mio host SVN ha iniziato a caricarsi per repo.

Il problema singolo o multiplo si riduce alle preferenze personali o organizzative.

La gestione del multiplo rispetto al singolo si riduce principalmente al controllo degli accessi e alla manutenzione.

Il controllo degli accessi per un singolo repository può essere contenuto in un singolo file; Più archivi possono richiedere più file. La manutenzione ha problemi simili: un grande backup o molti piccoli backup.

Gestisco il mio. C'è un repository, più progetti, ciascuno con i propri tag, trunk e rami. Se uno diventa troppo grande o ho bisogno di isolare fisicamente il codice di un cliente per il loro comfort, posso creare rapidamente e facilmente un nuovo repository.

Recentemente mi sono consultato con una società relativamente grande sulla migrazione di più sistemi di controllo del codice sorgente a Subversion. Hanno ~ 50 progetti, da applicazioni molto piccole a applicazioni aziendali e il loro sito web aziendale. Il loro piano? Inizia con un singolo repository, migra a più repository se necessario. La migrazione è quasi completa e si trovano ancora su un singolo repository, nessun reclamo o problema segnalato perché si tratta di un unico repository.

Questo non è un problema binario, in bianco e nero.

Fai ciò che funziona per te : se fossi nella tua posizione, combinerei i progetti in un unico repository il più velocemente possibile i comandi, perché il costo sarebbe una considerazione importante nella mia (molto, molto piccola) azienda.

JFTR:

i numeri di revisione in Subversion non hanno davvero alcun significato al di fuori del repository. Se hai bisogno di nomi significativi per una revisione, crea un TAG

I messaggi di commit sono facilmente filtrati per percorso nel repository, quindi leggere solo quelli relativi a un particolare progetto è un esercizio banale.

Modifica: vedere la risposta di Blade per i dettagli sull'utilizzo di una singola configurazione di autorizzazione / autenticazione per SVN.

Per il tuo caso specifico un (1) repository è perfetto. Risparmierai molti soldi. Incoraggio sempre le persone a utilizzare un unico repository. Perché è simile a un singolo filesystem: è più facile

• Avrai un unico posto in cui cercare il codice
• Avrai un'unica autorizzazione
• Avrai un unico numero di commit (hai mai provato a costruire un progetto distribuito su 3 repository?)
• Puoi riutilizzare meglio le librerie comuni e monitorare i tuoi progressi in queste librerie (svn: gli esterni sono PITA e non risolveranno tutti i problemi)
• I progetti pianificati come elementi completamente diversi, possono crescere insieme e condividere funzioni e interfacce. Questo sarà molto difficile da ottenere in più pronti contro termine.

C'è un unico punto per più repository: l'amministrazione di enormi repository è scomoda. Scaricare / caricare enormi repository richiede molto tempo. Ma poiché non fai alcuna amministrazione, penso che non sarà un tuo problema;)

SVN si adatta molto bene con repository più grandi, non c'è rallentamento anche su repository enormi (> 100 GB).

Quindi avrai meno problemi con un singolo repository. Ma dovresti davvero pensare al layout del repo!

Userei più repository. Oltre al problema di accesso dell'utente, semplifica anche il backup e il ripristino. E se ti trovi in ​​una posizione in cui qualcuno vuole pagarti per il tuo codice (e la sua storia), è più facile dargli solo un dump del repository.

Suggerirei che il consolidamento dei repository solo a causa delle politiche di addebito del tuo provider di hosting non è una buona ragione.

Usiamo un unico repository. La mia unica preoccupazione era la scala, ma dopo aver visto il repository di ASF (700k revisioni e conteggi) ero abbastanza convinto che le prestazioni non sarebbero state un problema.

I nostri progetti sono tutti correlati, diversi moduli ad incastro che formano un insieme di dipendenze per una determinata app. Per questo motivo, un unico repository è l'ideale. Potresti volere trunk / rami / tag separati per ogni progetto, ma sei comunque in grado di eseguire il commit atomico di una modifica su tutta la tua base di codice all'interno di una singola revisione. Questo è fantastico per il refactoring.

Tieni presente che quando prendi la tua decisione, molti repository SVN possono condividere lo stesso file di configurazione.

Esempio (tratto dal link sopra):

Nel guscio:

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

File: /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

File: / 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

Vorrei creare repository separati ... Perché? I numeri di revisione e i messaggi di commit non avranno alcun senso se hai molti progetti non correlati in un solo repository, sarà sicuramente un grande casino a breve termine ...

Siamo una piccola azienda di software e utilizziamo un unico repo per tutto il nostro sviluppo. L'albero ha questo aspetto:

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

L'idea era che avremmo cliente e lavoro interno nello stesso repo, ma abbiamo finito per avere la nostra azienda come un "cliente" di se stessa.

Questo ha funzionato molto bene per noi e usiamo Trac per interfacciarlo. I numeri di revisione sono in tutto il repository e non sono specifici per un progetto, ma questo non ci separa.

Personalmente, creerei nuovi repository per ciascuno. Mantiene il processo di check out molto più semplice e rende l'amministrazione nel complesso più semplice, almeno per quanto riguarda l'accesso degli utenti e i backup. Inoltre, evita il problema del numero di versione globale, quindi il numero di versione è significativo su tutti i progetti.

In realtà, però, dovresti semplicemente usare git;)

un'altra cosa da considerare è il fatto che l'utilizzo di più repository fa perdere la possibilità di avere un logging unificato (comando svn log) questo da solo sarà un buon motivo per scegliere un singolo repository.

Uso TortuiseSvn e ho scoperto che l'opzione "Mostra registro" è uno strumento obbligatorio. sebbene i tuoi progetti non siano correlati, sono sicuro che troverai che avere informazioni globali centralizzate sui progetti incrociati (percorsi, bug id, messaggi e così via ...) è sempre utile.

Se prevedi di utilizzare uno strumento come trac che si integra con SVN, ha più senso utilizzare un repo per progetto.

Simile al suggerimento di Blade sulla condivisione dei file, ecco una soluzione leggermente più semplice, ma meno flessibile. Ho impostato il nostro in questo modo:

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

In "bin", tengo uno script chiamato svn-create.sh che farà tutto il lavoro di installazione per creare un repository vuoto. Tengo anche lo script di backup lì.

In "repository_files", mantengo le directory "conf" e "hooks" comuni a cui tutti i repository hanno collegamenti simbolici. Quindi, c'è solo un set di file. Tuttavia, ciò elimina la possibilità di avere un accesso granulare per progetto senza interrompere i collegamenti. Non era un problema dove l'ho impostato.

Infine, tengo la directory principale / var / svn sotto il controllo del codice sorgente ignorando tutto in svnroot. In questo modo anche i file e gli script del repository sono sotto il controllo del codice sorgente.

#!/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)"

Simile a mlambie di utilizzare un singolo repository, ma è andato un po 'oltre con la struttura delle cartelle per ingrandire facilmente un particolare tipo di progetti: progetti basati su web html vs cs (C #) vs sql (script di creazione / esecuzione SQL) vs xyz ( Linguaggi specifici del dominio come afl (AmiBroker Formula Language) o ts (TradeStation)):

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

Nota, ho un tronco che vive all'interno di rami poiché lo tratto come ramo predefinito. L'unico problema a volte è quando si desidera creare rapidamente un altro progetto, è necessario creare la struttura ProjectName / branch | tags. Uso le impostazioni delle app semplicemente come luogo in cui mantenere i file di impostazioni delle app specifici nel repository così facilmente condivisibili con gli altri (e sostituire ClientName con VendorName e ProjectName con AppName in questa struttura di cartelle; e i tag | branch possono essere utili per contrassegnare le impostazioni in diversi major anche versioni di prodotti del fornitore).

Benvenuti a qualsiasi commento sulla mia struttura: di recente l'ho cambiato in questo e finora sono abbastanza felice, ma a volte trovo gravoso mantenere le strutture branch | tag per progetto, in particolare se il progetto è semplicemente una configurazione di progetto semplicemente per testare un altro progetto.

Il mio suggerimento è uno. A meno che tu non abbia utenti diversi che accedono a ciascuno di essi, direi di utilizzare più.

Ma ancora una volta, anche questo non è un buon motivo per utilizzare più.