Gérez vos dépôts subversion avec USVN

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes :
0
30
mai
2007
PHP
Userfriendly SVN est une interface web permettant la configuration de dépôts Subversion. Cette interface permet de facilement créer de nouveaux projets sans le client en ligne de commande et donc avoir un accès privilégié sur le serveur. USVN se chargera ensuite de gérer la liste des utilisateurs autorisés à récupérer votre code source. Cela permet de déléguer l'administration de vos dépôts Subversion.

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.
USVN est un projet Open Source redistribué sous licence CeCILL. Qu'est-ce que 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

  • # svn+ssh

    Posté par  (site web personnel) . Évalué à 4.

    Petite question : seule l'authentification apache est gérée, pas svn+ssh ?
    • [^] # Re: svn+ssh

      Posté par  . Évalué à 2.

      Pour l'instant oui.

      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  . Évalué à 5.

        Nous pensons aussi que c'est le moyen le plus simple de mettre en place son serveur subversion.

        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  . Évalué à 0.

          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).

          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  . É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  (site web personnel, Mastodon) . Évalué à 5.

      ouai enfin, personnellement, je ne suis pas fan de mettre une plethore de projets dans un même dépot. Les numéros de versions (commits) n'ont alors plus de sens. Un numéro de version est censé representé un état N d'un projet. Si il y a plusieurs projets, alors pour un projet donné, il y a pleins de numéro de versions qui correspondent à un même état de ce projet.

      Ç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  . Évalué à 4.

        Le no de révision ne devraient pas être utilisés pour reférencer des baseline du projet. Il faut utiliser les cheap copy et organiser son arborescence en conséquence (sous-répertoires branches et label) et extraire depuis ses répertoires en lecture ou en écriture.

        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  . Évalué à 2.

        Effectivement, c'est l'organisation que j'ai mis en oeuvre dans ma boîte : un dépot SVN et un Trac par projet. Ca permet d'archiver facilement d'anciens projets et je règle les droits accès pour chaque projet indépendemment.
        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  . Évalué à 4.

          Quand on inclut du code extérieur en svn:externals, il est fortement recommandé d'associer un numéro de révision du projet exterieur à la propriété. Dans ce cas, la création d'un tag ne pose aucun problème.
        • [^] # Re: Je vois pas le rapport

          Posté par  . Évalué à 1.

          Je vais devoir mettre en place le meme systeme. Est-ce que tu as un pointeur sympa sur un tutoriel qui explique comment faire ?

          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  . Évalué à 2.

            En fait, non, je n'ai pas de tutoriel, j'ai juste une petite note qui liste les différentes actions à effectuer :
            - 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  (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  . Évalué à 2.

        On peut avoir plusieurs projet dans un seul dépot svn et un trac par projet.

        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  (site web personnel) . Évalué à 2.

          Tiens puisqu'on en parle, est-ce qu'il est possible avec SVN de séparer une zone correspondant à un projet vers un nouveau dépôt ?

          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  . É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.
  • # Typo

    Posté par  . Évalué à 0.

    Le troisième lien devrait être « Site officiel de subversion »
    • [^] # Re: Typo

      Posté par  . Évalué à 0.

      Et suis-je le seul à être choqué par le mauvais anglais du site ?

      USVN permit an easy acces to a thin acess restriction on Subversion files.

      Un projet de l'epitech...
      • [^] # Re: Typo

        Posté par  (site web personnel) . Évalué à 2.

        Sans critiquer le niveau d'anglais (le mien n'étant pas terrible du tout) ni la tournure des phrases, je pense qu'une relecture du texte aurait permis de corriger au moins les grosses fautes :
        - 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  . Évalué à 1.

          "USVN is a End of studies project"
          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  (site web personnel) . Évalué à 2.

    .. à pousser plus loin à mon avis !

    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  . Évalué à 2.

      Mon rêve (mais ça viendrait clairement empiéter sur des applis commerciales propriétaires), ça serait l'intégration des fonctionnalités USVN avec quelques choses comme Trac :
      - 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 !
  • # Gestion checkout/update pour mise en ligne ?

    Posté par  . Évalué à 0.

    Je cherche quelque chose de ce genre (interface web) pour mettre
    à 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  (site web personnel) . Évalué à 4.

      USVN ne permet pas de faire ce genre de chose a l'heure actuel par contre c'est faisable en utilisant SVN.

      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.