Un référentiel SVN ou plusieurs?

Si vous avez plusieurs projets non liés, est-ce une bonne idée de les mettre dans le même référentiel?

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

ou créeriez-vous de nouveaux référentiels pour chacun?

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

Quels sont les avantages et les inconvénients de chacun? Tout ce à quoi je peux actuellement penser, c'est que vous obtenez des numéros de révision mixtes (et alors?), Et que vous ne pouvez pas utiliser à svn:externalsmoins que le référentiel ne soit réellement externe. (je pense?)

La raison pour laquelle je pose la question est que j'envisage de consolider mes multiples dépôts en un seul, car mon hôte SVN a commencé à facturer par dépôt.

Le problème unique ou multiple se résume aux préférences personnelles ou organisationnelles.

La gestion du multiple vs single se résume principalement au contrôle d'accès et à la maintenance.

Le contrôle d'accès pour un référentiel unique peut être contenu dans un seul fichier; Plusieurs référentiels peuvent nécessiter plusieurs fichiers. La maintenance a des problèmes similaires - une grosse sauvegarde ou beaucoup de petites sauvegardes.

Je gère le mien. Il existe un référentiel, plusieurs projets, chacun avec ses propres balises, tronc et branches. Si l'un devient trop gros ou si j'ai besoin d'isoler physiquement le code d'un client pour son confort, je peux créer rapidement et facilement un nouveau référentiel.

J'ai récemment consulté une entreprise relativement importante sur la migration de plusieurs systèmes de contrôle de code source vers Subversion. Ils ont environ 50 projets, allant des applications très petites aux applications d'entreprise et leur site Web d'entreprise. Leur plan? Commencez avec un seul référentiel, migrez vers plusieurs si nécessaire. La migration est presque terminée et ils sont toujours sur un référentiel unique, aucune plainte ni aucun problème signalé car il s'agit d'un référentiel unique.

Ce n'est pas un problème binaire, noir et blanc.

Faites ce qui fonctionne pour vous - si j'étais à votre place, je combinerais les projets dans un référentiel unique aussi vite que je pourrais taper les commandes, car le coût serait une considération majeure dans ma (très, très petite) entreprise.

JFTR:

les numéros de révision dans Subversion n'ont vraiment aucune signification en dehors du référentiel. Si vous avez besoin de noms significatifs pour une révision, créez un TAG

Les messages de validation sont facilement filtrés par chemin dans le référentiel, donc lire uniquement ceux liés à un projet particulier est un exercice trivial.

Edit: Voir la réponse de Blade pour plus de détails sur l'utilisation d'une seule configuration d'autorisation / authentification pour SVN.

Pour votre cas spécifique, un (1) référentiel est parfait. Vous économiserez beaucoup d'argent. J'encourage toujours les gens à utiliser un seul référentiel. Parce qu'il est similaire à un système de fichiers unique: c'est plus facile

• Vous aurez un seul endroit où vous recherchez le code
• Vous aurez une seule autorisation
• Vous aurez un seul numéro de commit (avez-vous déjà essayé de construire un projet qui est réparti sur 3 dépôts?)
• Vous pouvez mieux réutiliser les bibliothèques communes et suivre votre progression dans ces bibliothèques (svn: les externes sont PITA et ne résoudront pas tous les problèmes)
• Les projets planifiés comme des éléments totalement différents peuvent évoluer ensemble et partager des fonctions et des interfaces. Cela sera très difficile à réaliser dans plusieurs dépôts.

Il y a un seul point pour plusieurs dépôts: l'administration d'énormes dépôts est inconfortable. Le vidage / chargement d'énormes dépôts prend beaucoup de temps. Mais comme vous ne faites aucune administration, je pense que ce ne sera pas votre souci;)

SVN évolue très bien avec des référentiels plus volumineux, il n'y a pas de ralentissement même sur des référentiels énormes (> 100 Go).

Ainsi, vous aurez moins de tracas avec un seul référentiel. Mais vous devriez vraiment penser à la mise en page du dépôt!

J'utiliserais plusieurs référentiels. En plus du problème d'accès utilisateur, cela facilite également la sauvegarde et la restauration. Et si vous vous trouvez dans une position où quelqu'un veut vous payer pour votre code (et son historique), il est plus facile de leur donner juste un vidage de référentiel.

Je dirais que la consolidation des référentiels uniquement à cause des politiques de facturation de votre fournisseur d'hébergement n'est pas une très bonne raison.

Nous utilisons un référentiel unique. Ma seule préoccupation était l'échelle, mais après avoir vu le référentiel d'ASF (700k révisions et comptage), j'étais assez convaincu que les performances ne seraient pas un problème.

Nos projets sont tous liés, différents modules imbriqués qui forment un ensemble de dépendances pour une application donnée. Pour cette raison, un référentiel unique est idéal. Vous voudrez peut-être des troncs / branches / balises séparés pour chaque projet, mais vous êtes toujours en mesure de valider de manière atomique une modification sur l'ensemble de votre base de code dans une seule révision. C'est génial pour la refactorisation.

Sachez que lorsque vous prenez votre décision, de nombreux dépôts SVN peuvent partager le même fichier de configuration.

Exemple (tiré du lien ci-dessus):

En coque:

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

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

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

Je créerais des référentiels séparés ... Pourquoi? Les numéros de révision et les messages de validation n'auront aucun sens si vous avez beaucoup de projets non liés dans un seul référentiel, ce sera à coup sûr un gros gâchis à court terme ...

Nous sommes une petite entreprise de logiciels et nous utilisons un seul dépôt pour l'ensemble de notre développement. L'arbre ressemble à ceci:

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

L'idée était que nous aurions le travail client et interne dans le même repo, mais nous avons fini par avoir notre entreprise comme un «client» d'elle-même.

Cela a très bien fonctionné pour nous, et nous utilisons Trac pour s'y connecter. Les numéros de révision concernent l'ensemble du référentiel et ne sont pas spécifiques à un projet, mais cela ne nous met pas en phase.

Personnellement, je créerais de nouveaux référentiels pour chacun. Il simplifie considérablement le processus de vérification et facilite l'administration dans son ensemble, au moins en ce qui concerne l'accès des utilisateurs et les sauvegardes. En outre, cela évite le problème du numéro de version global, de sorte que le numéro de version est significatif sur tous les projets.

Vraiment cependant, vous devriez simplement utiliser git;)

une chose supplémentaire à considérer est le fait que l'utilisation de plusieurs référentiels vous fait perdre la possibilité d'avoir une journalisation unifiée (commande svn log), ce seul sera une bonne raison de choisir un référentiel unique.

J'utilise TortuiseSvn et j'ai trouvé que l'option "Afficher le journal" est un outil obligatoire. bien que vos projets ne soient pas liés, je suis sûr que vous trouverez qu'il est toujours utile d'avoir une information globale centralisée sur les projets croisés (chemins, identifiants de bogues, messages, etc.).

Si vous envisagez d'utiliser ou utilisez un outil comme trac qui s'intègre à SVN, il est plus judicieux d'utiliser un dépôt par projet.

Semblable à la suggestion de Blade sur le partage de fichiers, voici une solution légèrement plus simple, mais moins flexible. J'ai configuré le nôtre comme ceci:

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

Dans "bin", je garde un script appelé svn-create.sh qui fera tout le travail d'installation de la création d'un dépôt vide. J'y garde également le script de sauvegarde.

Dans "repository_files", je garde les répertoires "conf" et "hooks" communs vers lesquels tous les dépôts ont des liens sym. Ensuite, il n'y a qu'un seul ensemble de fichiers. Cela élimine la possibilité d'avoir un accès granulaire par projet sans rompre les liens. Ce n'était pas un problème où j'ai mis cela en place.

Enfin, je garde le répertoire principal / var / svn sous le contrôle de code source en ignorant tout dans svnroot. De cette façon, les fichiers et scripts du référentiel sont également sous contrôle de code source.

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

Semblable à mlambie d'utiliser un seul dépôt, mais est allé un peu plus loin avec la structure de dossiers pour zoomer facilement sur un type particulier de projets - projets basés sur le HTML Web vs cs (C #) vs sql (scripts de création / exécution SQL) vs xyz ( Langages spécifiques au domaine comme afl (AmiBroker Formula Language) ou ts (TradeStation)):

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

Remarque, j'ai le tronc vivant dans les branches car je le traite comme la branche par défaut. Le seul problème parfois est que lorsque vous souhaitez créer rapidement un autre projet, vous devez créer la structure ProjectName / branches | tags. J'utilise les paramètres d'application simplement comme endroit pour conserver des fichiers de paramètres d'applications spécifiques dans le référentiel si facilement partageables avec d'autres (et remplacez ClientName par VendorName et ProjectName par AppName dans cette structure de dossiers; et les branches | balises peuvent être utiles pour baliser les paramètres sur différents principaux versions des produits des fournisseurs aussi).

Bienvenue dans tous les commentaires sur ma structure - je l'ai récemment changé pour cela et jusqu'à présent assez heureux, mais je trouve parfois fastidieux de maintenir les structures de branches | tags par projet - en particulier si le projet est simplement une configuration de projet simplement pour tester un autre projet.

Ma suggestion en est une. À moins que différents utilisateurs n'accèdent à chacun, je dirais alors d'en utiliser plusieurs.

Mais encore une fois, même ce n'est pas une bonne raison d'utiliser plusieurs.