Peser les facteurs de configuration pour la subversion

Question

J'ai un certain nombre de projets différents, environ 5, et un certain nombre de développeurs différents, environ 15, et certains des projets sont en subversion et certains ne le sont pas. Tous les développeurs travaillent sur des machines basées sur Windows avec TortoiseSVN, et le code des projets est un mish-mash de classique asp, et asp.net. Quel est le meilleur, comme dans le plus réactif, utile et facile à administrer, moyen d'avoir tous les projets sous subversion et avoir un accès authentifié pour tous les développeurs, à la fois lire et écrire? Certaines choses à considérer seraient de le diffuser via svnserve ou apache, ce qui signifie qu'il y a des problèmes de vitesse, la facilité d'administration des mots de passe accès/utilisateurs &, et la nécessité d'ouvrir un port pare-feu supplémentaire (si svnserve)

Il est également important de prendre en compte les avantages/inconvénients d'avoir plusieurs projets dans un référentiel par rapport à un projet par référentiel. La disparité de révision n'est pas vraiment un problème, mais il peut être trop long d'obtenir le journal si plusieurs projets se trouvent dans un même référentiel, mais est-ce compensé par une administration plus facile des utilisateurs?

Answer 1

• Je recommande d'utiliser un référentiel pour tous vos projets. Cela facilite grandement la configuration de l'accès pour vos développeurs. De plus, vous n'avez plus qu'à sauvegarder un seul référentiel. Non seulement cela, mais il vous permet également de copier facilement des fichiers (et de maintenir l'historique de ces fichiers) entre les projets. Cela n'arrivera probablement pas si souvent, mais ça le rend bien quand c'est le cas. Créer de nouveaux projets est alors aussi simple que 'svn mkdir'.

Et vous ne perdez pas beaucoup en utilisant un seul référentiel. Vous pouvez toujours configurer les autorisations d'accès à chaque projet comme bon vous semble.

Votre structure de répertoire svn pourrait ressembler à ce qui suit:

projects/ 
    proj1/ 
     trunk/ 
     branches/ 
     tags/ 
    proj2/ 
     trunk/ 
     branches/ 
     tags/ 
    ... 

• Quelle sont vos projets? L'utilisation de svn sur HTTPS fonctionne très bien, surtout si votre connexion réseau est rapide. HTTPS est également un système d'accès assez universel. À moins que vous ne vérifiiez constamment des centaines ou des milliers de fichiers (ou que vous n'essayiez pas de lancer des erreurs sur un fichier contenant des milliers de révisions), la différence de vitesse pourrait ne pas vous valoir le coup. Chez nous, nous utilisons svnserve et nous authentifions avec des tickets kerberos, mais c'est beaucoup plus difficile à configurer.

Answer 2

Je ne peux penser qu'à deux moyens: Utiliser svn via un tunnel SSH, ou utiliser svn pour tirer/pousser via HTTP via SSL via un serveur Web.

Je conserverais chaque projet dans son propre référentiel, en utilisant le format standard trunk/branches/tags pour chaque projet en tant que mise en page du référentiel. C'est une mise en page plus propre puisque chaque chose a son propre conteneur, et si l'une des bases de données Subversion est corrompue ou coincée, cela n'affecte pas tous les travaux sur tous les projets.

Answer 3

Si vous êtes tous sur des lignes relativement rapides, l'exécution de SVN via Apache 2 avec SSL est une excellente option. Aucun problème de pare-feu et l'authentification de l'utilisateur peut être effectuée par plusieurs méthodes. J'ai un compte SVN hébergé sur un autre continent, parce que SSL n'est pas si rapide mais acceptable, puisque c'est le code source dont nous parlons, pas trop de transfert de données. Si vous avez un serveur plus proche, je suis sûr que la performance sera assez bonne.

Dépôts multiples: Je dirais que les problèmes de configuration sont pires que les problèmes de performance possibles. En conservant un seul référentiel, vous minimisez la configuration.

Answer 4

Je recommande

1. Apache, pas svnserve-- il est assez rapide, firewall- et proxy convivial, et l'utilisateur admin est le même travail de toute façon. Je trouve également très utile de pouvoir parcourir mes dépôts avec un navigateur.

2. Uniquement un référentiel, avec un dossier pour chaque projet contenant des lignes de réseau/branches/étiquettes. C'est beaucoup plus flexible que je ne le pensais au début, et dans de nombreux cas, vous n'avez pas besoin des sous-répertoires pour les troncs/branches/tags. Il est beaucoup plus facile de gérer un seul référentiel, et vous avez le contrôle de version, donc vous n'avez pas à vous soucier des utilisateurs qui gâchent les projets des autres ou quoi que ce soit.

Answer 5

Projets multiples contre projet unique:

Si le code est commun et les fichiers se déplacer, utiliser un référentiel. Si le code est isolé, utilisez plusieurs. Rappelez-vous que:

1. Un référentiel unique fait déplacement du fichier répertoire & renommer facilement et contrôlé
2. Un changement dans un référentiel se cogne le numéro de révision partout dans ce référentiel
3. La structure du répertoire physique développeur peut être différent du Structure svn

d'authentification

Utilisez apache, et SSL n'est pas nécessaire si vous configurez apache pour toujours s'authentifier.

<Location /svn/test> 
    DAV svn 
    SVNPath /svn/test 
    <LimitExcept GET PROPFIND OPTIONS REPORT> 
     AuthType Basic 
     AuthName "Authorization Realm" 
     AuthUserFile /svn/passwd 
     Require valid-user 
    </LimitExcept> 
</Location> 

Vous pouvez jouer avec ces règles pour exiger un mot de passe à la caisse ou non. Et vos mots de passe vivent dans ce fichier/svn/passwd.

Et ...

Utilisez aussi bien trac. Il s'intègre bien avec la subversion et offre aux développeurs une interface de subversion pour regarder leurs fichiers/changesets, etc.