Un seul dépôt SVN ou plusieurs ?

Question

Si vous avez plusieurs projets sans lien entre eux, est-ce une bonne idée de les mettre dans le même dépôt ?

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

ou faut-il créer de nouveaux dépôts pour chacun d'eux ?

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

Quels sont les avantages et les inconvénients de chacun ? Tout ce qui me vient à l'esprit actuellement, c'est que vous obtenez des numéros de révision mélangés (et alors ?), et que vous ne pouvez pas utiliser les numéros de révision de l svn:externals à moins que le référentiel soit en fait externe. (je pense ?)

La raison de ma question est que j'envisage de consolider mes multiples dépôts en un seul, puisque mon hébergeur SVN a commencé à facturer par dépôt.

Answer 1

La question de l'unicité ou de la multiplicité est une question de préférence personnelle ou organisationnelle.

La gestion d'un système multiple par rapport à un système unique se résume principalement au contrôle d'accès et à la maintenance.

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

Je gère le mien. Il y a un dépôt, plusieurs projets, chacun avec ses propres tags, tronc et branches. Si l'un d'eux devient trop gros ou si je dois isoler physiquement le code d'un client pour son confort, je peux rapidement et facilement créer un nouveau dépôt.

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 ~50 projets, allant de très petites applications à des applications d'entreprise et leur site Web d'entreprise. Leur plan ? Commencer avec un seul référentiel, migrer vers plusieurs si nécessaire. La migration est presque terminée et ils sont toujours sur un seul référentiel, aucune plainte ou problème n'a été signalé en raison du fait qu'il s'agit d'un référentiel unique.

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

Faites ce qui vous convient - Si j'étais à votre place, je regrouperais les projets en un seul dépôt aussi vite que je pourrais taper les commandes, parce que le coût serait une considération majeure dans ma (très, très petite) entreprise.

JFTR :

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éer un TAG

Les messages de validation sont facilement filtrés par chemin d'accès dans le référentiel, de sorte que la lecture des messages relatifs à un projet particulier est un exercice trivial.

---

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

Answer 2

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 dépôt. Parce que c'est similaire à un système de fichiers unique : Il est plus facile

• Vous aurez un seul endroit où chercher le code
• Vous disposerez d'une autorisation unique
• Vous aurez un seul numéro de commit (vous avez 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 vos progrès dans ces bibliothèques (svn:externals sont PITA et ne résoudront pas tous les problèmes).
• Les projets prévus comme des éléments totalement différents peuvent se développer ensemble et partager des fonctions et des interfaces. Ceci sera très difficile à réaliser dans des dépôts multiples.

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

SVN s'adapte très bien aux dépôts plus importants, il n'y a pas de ralentissement même sur des dépôts énormes (>100GB).

Vous aurez donc moins de problèmes avec un seul dépôt. Mais vous devriez vraiment penser à la mise en page du repo !

Answer 3

J'utiliserais plusieurs dépôts. Outre la question de l'accès des utilisateurs, 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 histoire), il est plus facile de lui donner juste un dump du dépôt.

Je pense que la consolidation des référentiels uniquement en raison des politiques de tarification de votre hébergeur n'est pas une très bonne raison.

Answer 4

Nous utilisons un seul référentiel. Ma seule préoccupation était l'échelle, mais après avoir vu Le dépôt d'ASF (700 000 révisions et plus), j'étais convaincu que les performances ne seraient pas un problème.

Nos projets sont tous liés, différents modules s'imbriquant les uns dans les autres et formant un ensemble de dépendances pour une application donnée. Pour cette raison, un seul dépôt est idéal. Vous pouvez vouloir des troncs/branches/tags séparés pour chaque projet, mais vous êtes toujours en mesure de commettre de manière atomique un changement sur l'ensemble de votre codebase dans une seule révision. C'est génial pour la refactorisation.

Answer 5

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

Exemple (tiré du lien ci-dessus) :

En coquille :

$ 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