Pourquoi choisir mod_dav_svn au lieu de svnserve & un explorateur de dépôt?

S'il vous plaît corrigez-moi si je me trompe sur ma compréhension de mod_dav_svn, qui est qu'il sert essentiellement 2 raisons:

  1. Exposer le dépôt SVN (sur le système de fichiers) aux clients, qui peuvent être soit:
    • référentiel des navigateurs (par exemple, web)
    • l' 'svn' commande en elle-même, qui est un client de ligne de commande du programme
  2. Agir comme un explorateur de dépôt pour effectuer le dépôt visible est une façon pratique de

Maintenant pour le point 1, sont mes hypothèses suivantes est correcte?

  • À tout moment d'un référentiel est accessible à l'aide mod_dav_svn, le http:// ou https:// forme d'accès au référentiel est utilisé
  • Si vous utilisez svnserve, le svn:// forme d'accès au référentiel est utilisé
    • Dans ce cas, mod_dav_svn serait ne servent à rien d'utilisation supplémentaire

Pour le point 2, si l'utilisation Trac du référentiel de fonctionnalités de navigation, il n'y a pas d'utilisation supplémentaire pour le dépôt de fonctionnalités de navigation offertes par mod_dav_svn?

Ne mod_dav_svn servir à toute autre fin, je n'ai pas décrits ici? Demande d'une autre manière, est-il un inconvénient à aller avec svnserve et Trac?

Je demande parce que j'ai l'impression que mod_dav_svn est très couramment utilisé, donc je me demande ce que je suis absent.

OriginalL'auteur user779159 | 2011-06-03

  1. 15

    Oublier le Point n ° 2: HTTP Navigation. C'est juste un petit bonus. Il ne remplace pas votre besoin de quelque chose comme Fisheye, ViewVC, ou (mon préféré) Sventon.

    Il ya quelques inconvénients de l'utilisation d'Apache http sur votre serveur Subversion:

    • C'est plus lent
    • Il est plus difficile de configuration

    Puis, il y a des avantages:

    • Il utilise un port standard (80) qui n'est pas normalement bloqué par les pare-feu.
    • Il peut être intégré avec LDAP et Active Directory
    • Vous pouvez utiliser HTTPS qui permet de chiffrer les mises à jour et les départs (y compris les mots de passe utilisateur).
    • Vous pouvez avoir plusieurs référentiels d'utiliser la même instance d'Apache httpd. Avec svnserve, vous ne pouvez faire qu'un seul dépôt par exemple et si vous avez plusieurs référentiels sur un système, vous devrez exécuter chaque svnserve processus sur un port non standard.

    Mon point de vue personnel: Si vous faites un environnement d'entreprise, les avantages de l'utilisation du protocole HTTP ou HTTPS façon l'emportent sur les inconvénients. Si vous parlez d'un petit dépôt et que vous et vos amis, je lance svnserve simplement en raison de la baisse des frais généraux et une installation plus facile. Toutefois, dans ces circonstances, je viens d'utiliser Github et vous inquiétez pas à ce sujet.

    - Je exécuter la Subversion que mon système de contrôle de source sur ma machine, et j'utilise svnserve dans cette instance.

    Merci, certains des questions de suivi. 1) Quand j'ai accès à une URL sur mon serveur svn svn://serveur/repo, n'est-ce pas utiliser le port 80? 2) Si l'intégration LDAP ne peut pas être fait pour svnserve, est la seule manière dont les utilisateurs peuvent s'authentifier est si ils sont dans le fichier indiqué par mot de passe-db dans svnserve.conf pour svn://ou qui ont un compte shell pour svn+ssh://? 3) ne Peuvent pas le même niveau de protection offert par https://être offerts par svn+ssh://, ou est-il une différence? (Désolé je ne peux pas mettre les paragraphes ici, il soumet chaque fois que j'ai frappé entrer suis-je en train de faire.) –

    1. C'est en utilisant le port 3690 par défaut. Ceci peut être modifié lorsque vous exécutez svnserve, mais alors votre svn URL doit refléter le fait que trop.

    2. Assez bien vrai. La plupart des endroits qui utilisent svnserve utiliser le fichier passwd. Cependant, depuis la version 1.5, vous pouvez utiliser SASL. Cependant, je n'ai jamais vu personne l'utiliser.

    3. Oui, ssh+svn://offre de paquets cryptés. Cependant, SSH peut être difficile à mettre en œuvre. Fondamentalement, la svnserve processus doit être généré et exécuté pour cet utilisateur particulier. Cela signifie que chaque utilisateur a besoin d'direct accès en lecture/écriture pour le référentiel. Vous avez besoin pour l'installation de umask pour chaque utilisateur et de créer une Subversion groupe Unix tout le monde appartient à. Ensuite, étant donné que ces utilisateurs ont un accès direct aux fichiers du référentiel, les empêcher de se connectant sur le serveur de dépôt. Le Manuel En Ligne a tous les détails. Mais, en fin de compte, il ne fonctionne que sur les serveurs Unix et Unix clients. Les clients Windows n'avez pas SSH sur eux, et auraient à installer. Je l'ai essayé quelques fois, mais https://est beaucoup plus facile.

    Merci, certains des questions de suivi. 1) Quand j'ai accès à une URL sur mon serveur svn svn://serveur/repo, n'est-ce pas utiliser le port 80? 2) Si l'intégration LDAP ne peut pas être fait pour svnserve, est la seule manière dont les utilisateurs peuvent s'authentifier est si ils sont dans le fichier indiqué par mot de passe-db dans svnserve.conf pour svn:// ou qui ont un compte shell pour svn+ssh://? 3) ne Peuvent pas le même niveau de protection offert par https:// être offerts par svn+ssh://, ou est-il une différence? (Désolé je ne peux pas mettre les paragraphes ici, il soumet chaque fois que j'ai frappé entrer suis-je en train de faire.)
    A répondu que d'éditer mon commentaire
    Merci, donc, en ce qui concerne les ports et les pare-feu: 4) En termes de base, est ma compréhension correcte de pourquoi les non-80 port peut causer des problèmes: si je suis à un point d'accès sans fil et le type svn://serveur/repo de mon serveur distant, et que sans fil routeur bloque tous les non-80 ports, la demande n'est pas parce qu'il utilise le port 3690? Mais si je commence à svnserve sur le serveur sur le port 80, et je me connecter à svn://serveur:80/repo, il va fonctionner? 5) Si j'ai déjà httpd exécute sur le port 80, ne serait-il pas de travail, ou les demandes sur le port 80 sera remis à svnserve ou httpd basé sur le protocole de demande?
    Le problème est généralement de pare-feu d'entreprise, et non pas des systèmes. Mon routeur local, je peux faire une exception en cas de besoin (et la plupart ne permettent svnserve par défaut). Toutefois, l'entreprise IL les gens peuvent être assez limité et il peut être impossible de les amener à faire une exception. Je suppose que vous pouvez exécuter svnserve sur le port 80, mais vous devez être root parce que les ports qui relèvent de 1024 réserve l'accès à la racine. HTTP contourne ce en quelque sorte, alors il est possible que vous pouvez obtenir autour de trop.
    Je ne recommanderais pas de course svnserve sur le port 80, à moins que vous êtes désespéré et n'avons pas d'autre option. Si vous l'avez fait, svnserve aurait toutes sortes de trafic attend du port 80 par le port HTTP, et je ne suis pas sûr de savoir comment il va gérer cela. L'exécution de svnserve et un serveur HTTP sur le port va certainement causer des problèmes. Il est préférable d'éviter de re-définir les ports standard si possible.

    OriginalL'auteur

  2. 2

    La simplicité de svnserve en fait une évidence pour rapide et sale installe, surtout si vous êtes un déploiement sur Windows.

    Cependant, le moment que vous avez besoin de mémoriser beaucoup de mots de passe, et souhaite que le dépôt Subversion utiliser le même mécanisme de SSO qui est utilisé dans l'organisation, à l'aide d'Apache mécanismes d'authentification couplé avec mod_dav_svn aide beaucoup.

    Avant Subversion 1.7, mod_dav_svn de la performance a été dit d'être atroce et connu pour être plus lent que svnserve. Subversion 1.7 soi-disant offre une plus rapide et plus simple protocole HTTP, ce qui devrait faire mod_dav_svn utilisation plus agréable au goût.

    OriginalL'auteur