Après avoir choisi Apache Subversion pour mes besoins de contrôle de la version (et ankhsvn / Tortoisisesvn pour mes principaux clients Subversion). Maintenant, j'essaie de choisir le serveur SVN pour fournir un accès à distance aux référentiels SVN. J'ai regardé quelques couple d'entre eux:
J'ai installé chacun dans une machine virtuelle pour les essayer mais n'a pas été trouvé suffisamment pour différencier la plupart d'entre eux suffisamment pour choisir une spécificité. Maintenant, j'ai quelques choses que je dois décider.
Je souhaite cependant que l'interface Web qui utilise un module Apache ou VisualSVN fournit. Je n'ai pas vraiment besoin de fournir mes trucs à d'autres (ni même à moi-même de mon système), donc ce n'est pas critique , mais cela permet certainement une extensibilité.
Je pensais que je devrais donner une petite information sur ma situation pour clarifier les choses.
1. J'ai lu que http est beaucoup
2. Après avoir choisi un protocole (en supposant que je avez choisir); J'ai besoin d'aide pour décider de quel fournisseur à utiliser. J'ai utilisé à l'origine le module Apache de la distribution Tigris. J'ai depuis supprimé que (Eh bien, juste le désactivé) et je suis actuellement en train d'utiliser VisualSvn (qui est http et donc lent). J'ai vu des gens souscrivant Sharp et Silk, mais ils semblent être plus petits, distros indie.
Collabnet d'autre part semble être plus élaboré que nécessaire. Fondamentalement, à moins que je puisse être convaincu pour l'un de ceux-ci, j'essaie principalement de choisir entre le Tigre et VisualSvn officiel.
3. J'ai également essayé de jouer avec SSL sans beaucoup de succès (je ne peux pas me permettre un vrai CA, alors j'utilise un certificat auto-signé dans VisualSvn). Je serais heureux d'utiliser svn + ssh / https, mais si je l'utilise sur mon propre système, ce n'est pas nécessaire, et si je l'utilise à l'extérieur, mon certificat auto-signé ne vous aidera pas.
Je suppose que je pouvais même utiliser un référentiel local; Je penserais que ce serait le plus rapide. Cependant, je préférerais une solution plus formelle au cas où j'y développerai. (J'ai envisagé simplement d'utiliser le client TortiseVn pour effectuer le travail du serveur localement.)
Donc, en résumé, j'ai besoin de conseils sur quel serveur (
Merci beaucoup.
4 Réponses :
En d'autres termes, si vous décidez d'essayer un serveur maintenant, vous pouvez passer à un autre type de serveur plus tard, sans perdre vos référentiels. Bien sûr, des copies de travail et de références externes absolues que vous avez apportées dans vos projets devront changer, mais vous pouvez garder vos référentiels avec l'histoire et tous.
J'ai installé VisualSvn Server quand il a été annoncé, et en était assez content, pour un tandis que.
Cependant, des problèmes de vitesse m'ont permis de passer au serveur SVNserve principal qui est expédié dans le cadre du package de ligne de commande Subversion.
Le problème principal, c'est que je travaille avec .NET et j'ai choisi d'ajouter plusieurs références de subversion externes à mes projets.
Premièrement, et avant tout, chaque projet que je fais dans ma bibliothèque de classe est signé par ma clé. Deuxièmement, des bibliothèques externes de 3ème partie, telles que SQLite et Nunit a été ajouté en tant que références externes.
Chaque projet avait leurs propres références externes. Je l'ai fait pour pouvoir créer un nouveau projet d'application, puis effectuer de nouvelles références externes aux parties de ma bibliothèque de classe dont j'avais besoin, et pour que ces références soient complètes. Si ma solution de bibliothèque de classe dans .NET avait une référence externe pour le fichier de clé de signature et que ce fichier n'était pas disponible dans un seul projet, mais était situé sur le disque en dehors de tous les projets, mais local à ma solution, qui serait pas avoir travaillé.
Donc, ma solution de bibliothèque de classe contient environ 15 à 20 projets, chacun ayant au moins une référence externe à la clé de signature, tous mes projets de données ont des références externes à la bibliothèque SQLite et la bibliothèque de tests d'unité ayant 4-5 externes Références.
Le résultat net était qu'une seule mise à jour au niveau de la solution, même si j'avais déjà tous les derniers dossiers, les répertoires, tout a pris environ 2 minutes à compléter. Toutes les références externes prenaient quelque part entre 10 et 20 secondes pour terminer, juste pour vérifier que j'avais la révision dont j'avais besoin.
Lorsque je passe à Svnserve, ces 2 minutes ont été réduites à environ 3 secondes. C'est un état de trafic local vous, bien sûr, cela va différer sur Internet. Le problème est que ces 2 minutes étaient également du trafic local.
Ainsi, alors que j'apprécie absolument l'interface VisualSvn Server m'a fourni, y compris la possibilité de facilement configurer les droits d'accès et les utilisateurs, la vitesse que le module de serveur Apache m'a fourni était absolument horrible dans Comparaison avec ce que Svnserve et le protocole de subversion native.
Notez que j'ai depuis été installé depuis ensuite un serveur Apache distinct, érayé par de nombreux fichiers de configuration et configurez la subversion avec Apache autre que via VisualSvn Server, juste pour vous assurer que ce n'était pas seulement Visualsvn, et j'ai confirmé que la vitesse que j'ai observée n'était pas le travail de l'équipe VisualSvn. Il semble que le protocole HTTP ou les modules Apache ne soit tout simplement pas si rapide.
Mon conseil est d'aller avec le serveur SVNserve principal, si possible. Cela peut prendre des travaux pour connaître les fichiers de configuration pour l'autorisation et les goûts, mais le seul facteur d'irritation (c.-à-d. Aucune irritation de la vitesse du tout) ne l'emportera probablement pas.
J'aime les informations sur les référentiels étant standard et donc portable. Cela me dit que je peux juste rester avec ce que j'ai qui fonctionne actuellement et change comme / si nécessaire.
Le protocole HTTP a été amélioré dans Subversion 1.7: subversion.apache.org/docs/ Livraison-Notes / 1.7.html # httpv2
J'utilise Collabnet à la maison et au travail. Cela fait bien - aucune plainte avec performance.
Reforce d'accès: j'ai vu un Apache Également, dans ce projet même, je devais apprendre que SVN sur un ext3 FS sous Linux était à des lois un ordre de grandeur plus rapide que sur NTFS sous Windows. Marquer que: Le Linux d'une machine virtuelle exécutée sous Windows a pris un dixième du temps pour une mise à jour en compétition avec la boîte Windows, le VM a couru sur . (Nous voulions toujours essayer d'essayer ce pilote OS ext3 pour Windows et voir si cela ne ferait pas plus de svn plus vite sur Windows que son natif fs. Cependant, j'ai quitté le projet avant que nous n'aurions jamais rencontré.)
Quoi qu'il en soit, ce n'est pas comme ce que vous décidez de vous lancer dans la pierre pour l'éternité. Vous pouvez essayer une chose, le tester à fond dans un véritable projet et passer à un autre serveur et protocole plus tard. (Il y a même une commande SVN pour commuter l'URL d'un arborescence de sortie vérifiée . Ceci que vous pouvez utiliser pour changer de protocole sans avoir à vérifier tout de nouveau.)
Voici ce que je voudrais décider de décider du protocole: si vous avez une infrastructure de travail de travail ou de LDAP que vous souhaitez exploiter pour vous connecter à SVN, essayez l'un des Je n'ai jamais vu un SVN repo que les gens utilisaient un accès WebDav. IME Ils veulent toujours avoir l'historique lors de l'accès au Web (webdav ne fournit pas cela, AFaik), ils ont donc utilisé l'une des parties Web pour SVN. Je n'ai jamais vérifié, mais je suppose juste que ViewVC et similaire Ne vous souciez pas du protocole ils utilisent pour accéder au repo.
Comme pour quelle distribution que vous souhaitez utiliser - je pense que c'est principalement des préférences personnelles, car le code en dessous est le même de toute façon. Je préfère les téléchargements Je n'ai pas à vous inscrire et à vous inscrire explicitement sur la plate-forme que je souhaite les installer. Mais c'est probablement juste moi.
Cependant, il y a un fait difficile, vous voudrez peut-être envisager si votre référentiel est accessible à partir d'Internet: lorsque le projet SVN a effectué une nouvelle version de points, combien de temps le faisait, dans le passé, prenez les différentes distributions à rattraper. Comme ils pourraient être des correctifs de sécurité, vous préférez peut-être ceux qui, généralement, fournissent les correctifs plus rapidement. https: SVN STERVIND Ayant besoin d'une mise à jour matérielle. Il me semble que je me souviens que c'était principalement un manque de mémoire qui a ralenti les nombreux processus Apache qui ont participé aux ressources de la machine. Mais c'était dans 20 développeurs qui collaborent sur un projet avec un arbre choisi de 20 Go (beaucoup de binaires là-bas, qui ont souvent changé). Et la mise à jour d'un serveur modérément équipé a résolu le problème.
http / https: options de protocole. Si vous n'avez pas cela, et vous n'en aurez pas besoin, et vous allez bien faire la connexion par les moyens de SVN, pourquoi ne pas utiliser la vitesse fournie par le protocole SVN: ?
Nous fournissons nos référentiels SVN à l'aide de HTTP fourni par Apache exécutant sous Centos 5.3 à l'intérieur d'une machine virtuelle Xen.
J'aurais observer cela faire un commit ou une caisse sur un fichier volumineux, transfère ce fichier à proximité de la vitesse du réseau. Tout en vérifiant ou commettre un grand nombre de petits fichiers, la surcharge des demandes HTTP est beaucoup plus perceptible.
Par rapport aux délais dans la compilation du code, Subversion n'est pas considérée comme un goulot d'étranglement à l'intérieur de la société.
(C'est mon expérience avec une équipe de 10 développeurs)
Je suis toujours noabish, mais je suppose que c'est une question qui serait correctement posée sur Serverfault: serverfault.com
J'ai plusieurs projets de 100 Mo utilisant uniquement l'accès HTTP. La performance n'est pas un problème, du tout. Je ne m'inquiéterais pas ou ne vous inquiétez pas avec SVN: // jusqu'à ce que la performance soit un véritable problème pour vous.