svn+ssh

• [^]Re: svn+ssh

  Posté par stem () le 30/05/2007 à 15:20. (lien). É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 Batmat (page perso, ) le 30/05/2007 à 19:28. (lien). É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 Aurélien Le Provost - Ribaltch (page perso, ) le 01/06/2007 à 09:56. (lien). É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.

      --
      Encryption is not magic pixie dust to sprinkle on things to make them more secure.

Je vois pas le rapport

• [^]Re: Je vois pas le rapport

  Posté par Laurent J (page perso, ) le 30/05/2007 à 13:55. (lien). É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 Bozo le Clown () le 30/05/2007 à 15:06. (lien). É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 Frédéric COIFFIER () le 31/05/2007 à 08:11. (lien). É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 Barnabé () le 31/05/2007 à 10:24. (lien). É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 okparanoid () le 31/05/2007 à 18:33. (lien). É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 Frédéric COIFFIER () le 09/06/2007 à 16:04. (lien). É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 Julien Duponchelle (page perso, ) le 30/05/2007 à 14:11. (lien). É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 kaouete (page perso, ) le 30/05/2007 à 14:38. (lien). É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 ccomb (Jabber id, page perso, ) le 31/05/2007 à 09:43. (lien). É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 Julien Duponchelle (page perso, ) le 01/06/2007 à 08:34. (lien). Évalué à 1.

        Je suis sur que c'est faisable mais je ne suis pas sur qu'un outil le fasse actullement en automatique.
        
        Jette peut etre un oeil a svn-mirror.

      • [^]Re: Je vois pas le rapport

        Posté par Olivier Serve (Jabber id, page perso, ) le 01/06/2007 à 08:37. (lien). Évalué à 1.

        Oui, c'est possible.
        
        

        
        svnadmin create /var/svn/repos2
        svnadmin dump /var/svn/repos | svnadmin load /var/svn/repos2
        

        
        
        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 () le 01/06/2007 à 11:52. (lien). Évalué à 1.

          Il y a quelques infos là-dessus dans une section du SVN book [http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.(...)]; en plus de svnadmin il faut utiliser l'outil svndumpfilter pour ne garder que ce que l'on veut. Je n'ai jamais testé mais cela à l'air faisable sans trop de difficultés.

  • [^]Re: Je vois pas le rapport

    Posté par Sébastien Douche () le 31/05/2007 à 08:35. (lien). É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 (page perso, ) le 31/05/2007 à 08:43. (lien). Évalué à 1.

      Effectivement autant pour moi en parcourant la doc je ne l'avais pas vu.

Typo

• [^]Re: Typo

  Posté par seeschloss () le 30/05/2007 à 13:42. (lien). É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 Q. (Jabber id, page perso, ) le 30/05/2007 à 14:52. (lien). É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 Mathieu Fortin (page perso, ) le 31/05/2007 à 13:03. (lien). É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 ...

• [^]Re: Très bonne idée ...

  Posté par Frédéric COIFFIER () le 31/05/2007 à 08:30. (lien). É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 !

  • [^]Re: Très bonne idée ...

    Posté par Bozo le Clown () le 31/05/2007 à 11:18. (lien). Évalué à 4.

    As tu déjà etudié Libresource ?
    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 ?

• [^]Re: Gestion checkout/update pour mise en ligne ?

  Posté par Julien Duponchelle (page perso, ) le 31/05/2007 à 08:42. (lien). É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.