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.