USVN permet un accès facile à la gestion fine des droits d'accès sur les fichiers de subversion. Cela permet par exemple de n'autoriser aux traducteurs des modifications que sur les fichiers de traduction en quelques clics.
Les fonctionnalités supportées par USVN pour cette version sont :
- Création et suppression de dépôt USVN
- Génération du fichier htpasswd à partir de la liste d'utilisateurs d'USVN
- Gestion fine des droits sur les fichiers sur le Subversion.
Subversion est un logiciel libre de gestion de sources. Il permet de gérer un dépôt central pour votre code source dans lequel les développeurs pourront envoyer et récupérer leurs modifications. Subversion permet de garder les différentes versions de votre projet et de pouvoir y retourner. SVN permet de gérer les conflits entre les modifications de différents développeurs en leur présentant les modifications en cause.
Pourquoi avoir fait USVN?
USVN part du constat que Subversion est un outil fantastique, mais qu'on n'utilise qu'une partie de ses capacités. Par fainéantise, on ne crée pas toujours un dépôt par projet, mais on met tout dans le même perdant ainsi la gestion de branche et de tags. On exploite rarement aussi la capacité de Subversion à donner des droits très fins sur un fichier ou un dossier du dépôt. De plus, il faut généralement posséder un accès root sur la machine pour toucher à la configuration de Subversion (il faut pouvoir modifier certains fichiers d'Apache). Tout cela nous a poussé à faire une interface permettant une gestion simple de Subversion qui permet de créer et gérer un projet en quelques clics.
Comment ça marche ?
Lors de son installation, USVN vous donne un bloc de configuration à mettre dans la configuration de votre Apache et après vous n'aurez plus jamais besoin de passer en root pour gérer vos dépôts Subversion. En effet, USVN se chargera pour vous de générer les fichiers htpasswd et et authz nécessaire au contrôle d'accès de Subversion couplé à Apache.
Quelles sont les fonctionnalités prévues ?
Dans une prochaine version USVN proposera la gestion des hooks Subversion. On pourra par exemple interdire les commits vides en un seul clic alors qu'actuellement on doit mettre un bout de script shell dans un fichier particulier du dépôt.
Ce projet est développé dans le cadre des projets de fin d'études à Epitech.
Aller plus loin
- USVN (561 clics)
- Captures d'écran (264 clics)
- Site officiel de subversion (66 clics)
# svn+ssh
Posté par Twidi (site web personnel) . Évalué à 4.
[^] # Re: svn+ssh
Posté par stem . Évalué à 2.
Nous pensons aussi que c'est le moyen le plus simple de mettre en place son serveur subversion.
Néanmoins, nous allons faire en sorte que cela soit possible. Je ne pense pas que nous pourrons fournir une solution toute en un comme ce que nous faisons à l'heure actuelle avec l'authentification apache mais cela sera possible.
Pour commencer, nous allons documenter ces installations un peu plus hasardeuses que celle que nous préconisons. Une petite contribution sera bien évidemment la bien venue ;)
[^] # Re: svn+ssh
Posté par Batmat . Évalué à 5.
Si vous parlez du côté utilisateur, alors oui. C'est vrai qu'un serveur disponible depuis le protocole HTTP/S est plus facilement accessible, depuis par exemple l'intérieur des entreprises, qui souvent mettent en place l'accès au Web via un proxy obligatoire (donc interdisant l'accès tout autre port que 80 ou 443).
Par contre, si vous parlez de mise en place du serveur, je ne suis pas d'accord du tout, le protocole svn:// avec svnserver est beaucoup plus simple et plus léger à mettre en ½uvre (pas besoin d'installer Apache2, mod_svn, mod_dav etc.).
[^] # Re: svn+ssh
Posté par Anonyme . Évalué à 0.
D'un autre côté c'est un peu normal de voir un accès web se baser sur les 2 ports standarts du protocole. Après si dans ta phrase il faut remplacer web par internet, alors je te réponds web ≠ internet.
# Je vois pas le rapport
Posté par Sébastien Douche . Évalué à 7.
USVN part du constat que Subversion est un outil fantastique, mais qu'on n'utilise qu'une partie de ses capacités. Par fainéantise, on ne crée pas toujours un dépôt par projet, mais on met tout dans le même perdant ainsi la gestion de branche et de tags. On exploite rarement aussi la capacité de Subversion à donner des droits très fins sur un fichier ou un dossier du dépôt.
Ca ne choque que moi cette partie ? Quel est le rapport entre la création d'un dépot par projet et la gestion fine ? On peut avoir plusieurs projets dans le même dépot avec les branches / tags (heureusement). De même il est possible de gérer les droits correctement dans un seul dépot.
Pour moi la création de dépôts est plus de l'ordre de l'administration système (partition, sauvegarde...) ou du découpage fonctionnel de la boite (par client, par pole d'activité..) que technique.
[^] # Re: Je vois pas le rapport
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Ça passe pour des projets de 10 lignes qu'on regroupe dans un même dépôt. Pour un projet minimum sérieux, il devrait avoir son propre dépôt.
Un exemple que je trouve justement mauvais est sur le projet KDE : je trouve la gestion de leur dépôt carrément bordélique. Je ne comprend pas l'intérêt de regrouper tous les projets dans un même dépôt. Surtout que subversion permet de lier les dépôts entre eux avec la propriété svn:externals sur les répertoires.
[^] # Re: Je vois pas le rapport
Posté par Bozo_le_clown . Évalué à 4.
Sinon l'interêt de séparer les dépots, c'est les performances (taille de la db) et également le fait d'eviter des fausses manips. (genre je copie la dernière version de mon projet au mauvais endroit i.e. sous l'arborescence d'un autre projet.
[^] # Re: Je vois pas le rapport
Posté par Frédéric COIFFIER . Évalué à 2.
Après la propriété svn:externals, elle est a double tranchant, par exemple quand on veut faire un tag d'un projet qui inclut du code extérieur en svn:externals.
[^] # Re: Je vois pas le rapport
Posté par Barnabé . Évalué à 4.
[^] # Re: Je vois pas le rapport
Posté par okparanoid . Évalué à 1.
Quand tu dis un trac par projet ca necessite de l'installer manuellement autant de fois que de projets ou c'est parametrable dans trac (creation de plusieurs instances) ?
Merci
[^] # Re: Je vois pas le rapport
Posté par Frédéric COIFFIER . Évalué à 2.
- svnadmin pour créer un repository Subversion
- tracadmin pour créer un projet Trac que je fais pointer sur le repository Subversion
- Ajout des entrées dans la config Apache pour l'accés à Subversion d'un côté et aux pages du projets Trac de l'autre côté
- Un fichier d'authentification Apache pour l'accès à Trac et à Subversion
- Installation des scripts hooks dans le repository Subversion du nouveau projet (ce qui permet de faire le lien entre un commit Subversion et un ticket Trac)
Je n'ai rien automatiser vu que je crée un nouveau projet tous les 2-3 mois et qu'ensuite, je dois plus ou moins personnaliser les projets (composants, roadmap Trac, etc...)
[^] # Re: Je vois pas le rapport
Posté par Julien Duponchelle (site web personnel) . Évalué à 2.
Ca ne choque que moi cette partie ? Quel est le rapport entre la
création d'un dépot par projet et la gestion fine ? On peut avoir
plusieurs projets dans le même dépot avec les branches / tags
(heureusement). De même il est possible de gérer les droits
correctement dans un seul dépot.
Nous ne disons pas que la gestion des droits fine est impossible, mais que la façon dont est faite la configuration est actuellement un peu lourde, surtout que l'on peut difficilement la déléguer, car il
faut que les utilisateurs aient les droits sur le fichier en question.
Alors que notre interface permet de le faire en quelques clics.
Pour moi la création de dépôts est plus de l'ordre de l'administration
système (partition, sauvegarde...) ou du découpage fonctionnel de la
boite (par client, par pole d'activité..) que technique.
Effectivement, c'est une manière de voir les choses qui se justifie.
Mais avec cette approche, on ne peut pas mettre de hooks propres à
un projet (enfin c'est faisable en bricolant les scripts, j'en conviens,
mais ce n'est pas très "user friendly"). Un deuxième problème est que l'on ne peut pas avoir un Trac par projet. (je sais que c'est un problème spécifique, mais dans notre utilisation c'est un problème)
En conclusion, je dirais que l'on peut tout faire avec subversion, mais
que cette souplesse a un prix qui est celui de la simplicité.
[^] # Re: Je vois pas le rapport
Posté par Victor . Évalué à 2.
Par contre on ne peut pas _gérer_ plusieurs dépots ni projets avec un trac (bien qu'on peut avoir un trac pour plusieurs projets dans un même dépot ... je sais pas si vous me suivez là : )
[^] # Re: Je vois pas le rapport
Posté par ccomb (site web personnel) . Évalué à 2.
J'ai plusieurs projets dans un même dépôt et pour l'instant ça me va, mais j'aimerai avoir la possibilité à terme d'extraire un projet et de le mettre dans son propre dépôt et conservant tout l'historique, c'est possible ?
[^] # Re: Je vois pas le rapport
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
Jette peut etre un oeil a svn-mirror.
[^] # Re: Je vois pas le rapport
Posté par Olivier Serve (site web personnel) . Évalué à 1.
Puis supprimer ce qui dépasse dans repos2. C'est pas très propre, mais c'est le seul moyen que j'ai trouvé pour garder l'historique des révisions.
[^] # Re: Je vois pas le rapport
Posté par nigaiden . Évalué à 1.
[^] # Re: Je vois pas le rapport
Posté par Sébastien Douche . Évalué à 4.
Un deuxième problème est que l'on ne peut pas avoir un Trac par projet. (je sais que c'est un problème spécifique, mais dans notre utilisation c'est un problème)
Euh, pas du tout, puisque je fais comme ça tout le temps. Un projet Trac peut pointer sur n'importe quel noeud d'une arbo SVN, la racine du dépot comme un sous répertoire. Donc si tu as un projet dans /mondépot/projet1/, tu donnes à Trac ce lien comme racine du projet et ça roule. Trac est vraiment très souple.
[^] # Re: Je vois pas le rapport
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
# Typo
Posté par seeschloss . Évalué à 0.
[^] # Re: Typo
Posté par seeschloss . Évalué à 0.
USVN permit an easy acces to a thin acess restriction on Subversion files.
Un projet de l'epitech...
[^] # Re: Typo
Posté par Q. (site web personnel) . Évalué à 2.
- le s qui manque aux verbes à la 3ème personne du singulier
- it's means (le verbe est bien conjugué, mais le 's' est de trop)
- access (2 c, 2 s)
- witch au lien de with
- wich au lieu de which
On retrouve toutes ces fautes dans la doc.
Sinon, le projet m'intéresse bien, par contre, je ne trouve pas les dépendances (genre les modules apache/php nécessaires). J'ai aussi du mal à voir si c'est une couche au dessus de subversion ou bien si cela se greffe sur mes dépôts subversion existants. Ca parle d'importer des dépôts existants mais cela a t'il un impact coté client genre changement d'adresse du dépôt?
[^] # Re: Typo
Posté par Mathieu Fortin . Évalué à 1.
Ca se dit: "USVN is a final year project"
My 2cents ;)
Ps: sinon a part ca, tres bonne idee je vais y jeter un oeil et peut etre l'adopter !
# Très bonne idée ...
Posté par Philippe Poumaroux (site web personnel) . Évalué à 2.
Je pense que la navigation ne doit pas en faire partie, vu que websvn et viewcvs le font déjà. Mais la partie admin en ligne est très prometteuse, surtout pour les entités qui gèrent plusieurs projets et donc plusieurs dépôts:
- gestion des utilisateurs en ne se limitant pas au htpasswd (LDAP et/ou Bdd)
- gestion des droits comme c'est déjà le cas
- gestion des mails automatiques (commit.pl)
- gestion des sauvegardes (hotbackup)
- tableau de bord de synthèse des projets (derniers logs et commit via RSS)
Voilà ce que j'ai du mettre en place ... donc bravo et bon courage, ce n'est que le début !
[^] # Re: Très bonne idée ...
Posté par Frédéric COIFFIER . Évalué à 2.
- gestion de conf
- gestion de bug/changement
- multiprojet
- gestion des droits des utilisateurs (développeur (read-write), intégrateur (read-only), testeur(read-only))
- lien entre les composants définis par Trac et des dossiers Subversion pour par exemple, associer un développeur pour le développement/maintenance d'un composant au sein d'un projet.
Bref, ça serait pour se rapprocher de ce genre de chose :
http://www.telelogic.fr/products/synergy/synergycm/index.cfm
On n'en est pas très loin ! Il y a les éléments de bases, il manque plus que la sauce qui lie le tout !
[^] # Re: Très bonne idée ...
Posté par Bozo_le_clown . Évalué à 4.
http://dev.libresource.org/home/community/features
Toutes les features y sont et il ne reste qu'a vérifier le multiprojet.
# Gestion checkout/update pour mise en ligne ?
Posté par Vincent Knecht . Évalué à 0.
à jour une appli web à partir d'un dépôt subversion.
Idéalement, la version "test" serait mise à jour à chaque commit,
et la version "prod" pourrait être mise à jour en donnant un numéro
de révision ou un tag.
Si possible, ce serait bien de pouvoir mettre certaines infos spéciales
et/ou sensible dans un fichier de conf associé au site projet (comme
le compte utilisé pour la base de données), et ces infos seraient
automatiquement remplacées/intègrées dans les fichiers désignés
lors de "l'update".
Est-il envisageable qu'USVN fasse ce genre de chose ?
[^] # Re: Gestion checkout/update pour mise en ligne ?
Posté par Julien Duponchelle (site web personnel) . Évalué à 4.
Pour la version test j'utiliserais un hooks de post-commit afin de déclencher la mise a jour (sa c'est la solution propre ou un cron tres regulier c'est plus facile a faire).
Pour la version de production je ferais une branche qui comme pour la version de test serait mise a jour sur le serveur soit par un hook soit par un cron.
Pour les variables a remplacer je ne vois pas de solution puisque pour le moment subversion ne permet pas de creer ses propres mot clef a remplacer.
Dans une prochaine version de USVN nous supporterons l'installation et la configuration de hooks. Il faut encore que l'on reflechisse comment on peut donner l'ordre a un client de faire la mise jour.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.