(Courriels de diversion: <reverer@amortissait-renaîtront.com> <creuses@navigable-echos.com> <troues@regater-dignitaire.com> <obsequieuse@differenciation-limonadiers.com> <jouxtaient@mystificatrices-ecu.com> <regal@pacifies-fusillee.com> <astreindras@arceaux-outrerons.com> <cintrais@soldent-attributs.com> <exaucant@matrone-reiterative.com> <stoppee@bassement-carierait.com> )
le mercredi 02 mars à 17h02, Gilles.Martin@imft.fr (Gilles MARTIN) , enlutant avec son clavier, a réussi péniblement a écrire : > Bonjour, Bonjour > Je cherche à mettre en place pour une application existante (environ > 35000 lignes), un environnement de développement multi utilisateurs > avec gestion des versions. > > J'ai pensé à CVS/Cervisia, certains parlent de Eclipse... > > Quelqu'un d'entre vous a-t-il un conseil ? Je suis en plein dedans, mais pour de la doc sous latex. J'utilisais auparavant CVS en local, marche très bien. Puis j'ai eu besoin de rendre le dépôt accessible depuis le réseau, et de générer automatiquement les pdf à chaque commit. Là ça s'est compliqué. CVS sais très bien faire l'un et l'autre, mais nécessite pour la mise en réseau, il faut donner un accès au shell de la machine (via rsh ou ssh), ce qui me semble gênant pour un simple accès au dépôt CVS. De plus la génération du pdf depuis le fichier latex se fait sous le compte du pserver de svn, c'est à dire root. J'ai donc testé subversion et son serveur svnserve (pas la version apache2/webdav). L'intérêt de subversion est qu'on peut définir des utilisateurs et des droits indépendamment des comptes unix de la machine. Et le serveur ne tourne pas en root. On peu en plus limiter l'accès au dépôt sur le disque, au lieu de préciser le chemin depuis la racine (et oui sous cvs, à moins de chrooter, un utilisateur a accès à tous les dépôts de la machine, sous réserve des droits sur le système de fichier). Après, à l'utilisation, pour ce que j'en fait (pas de branches ni de version) svn est très proche de cvs : import, commit, checkout. Une différence que j'ai noté, on peut lister les projets du serveur, et la révision concerne l'ensemble du dépôt. Fini les numéros de révision indépendant sur chaque fichier. Pour subversion, le dépôt est un unique projet, et on peu travailler sur un sous répertoire de ce projet plutôt que sur l'ensemble. Du coup j'ai l'architecture suivante : doc/ serveur_linux cv conf/ routeur serveur_samba Pour la génération des pdf, j'ai utilisé le «hook» post-commit, un simple shell script exécuté après chaque commit. Je cherche les fichiers modifiés avec svnlook diff, des grep et des cut, puis le génère mon pdf que je place dans le ~/public_html de l'utilisateur svnowner. Si ça intéresse quelqu'un, je peux le poster. C'est minimal, très spécifique à nos besoins mais ça marche bien. Voila, pour moi, cvs est très bien en local, et en réseau si les utilisateurs ont un accès au shell de la machine qui héberge le dépôt. Subversion ne m'apporte que la gestion des utilisateurs indépendante des comptes unix et un serveur qui ne tourne pas en root. On peut supposer que la version openbsd de cvs qui sortira bientôt résoudra ces problèmes. Déjà leur anoncvs permet un accès en lecture seule via ssh à un dépôt, en anonyme. -- busab -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>