Logiciel de gestion de version / gestion de configuration

[DaHelmut]

Bonjour à tous,

Je suis entrain de mettre en place dans mon entreprise un système de gestion de version / gestion de configuration (SCM) afin de gérer les sources des projets LabVIEW.

Nous sommes en moyenne entre 2 à 3 développeurs à travailler sur le même projet, l'utilisation d'un tel système s'avère donc nécessaire.

J'ai pour le moment pu tester SUBVERSION avec succès (+ TortoiseSVN).

Je vais bientôt terminer de tester PERFORCE (gratuit jusqu'à 20 utilisateurs).

Je me demandais ce que le reste de la communauté utilisait ? Avez vous testé d'autre système ? (CVS, GIT, MERCURIAL, ...).

Qu'est ce qui vous a poussé à choisir tel ou tel système ?

Dans mon cas SUBVERSION est très facile à mettre en place, cependant l'administration pose problème, le chef de projet doit forcément aller sur le serveur pour créer les Repositories, ce qui est embêtant...Cet inconvénient n'est pas présent dans PERFORCE qui peut manager a distance les dossiers...

De plus PERFORCE s'intègre facilement à LabVIEW et est d'ailleurs utilisé par la R&D NI il me semble...

Je vous remercie de vos réponses.

Cordialement,

[Olivier-JOURDAN]

Salut,

nous utilisons depuis plus de 5 ans Subversion avec TSVN avec succès (en gros je pense pas qu'on pourrait développer sans, même sur un projet d'une semaine avec un seul développeur). On gère très bien des projets jusqu'à 5 ou 6 développeurs en même temps.

Pour ce qui est de la création des répo, chez nous, n'importe quels développeurs peux en créer, mais il faut reconnaitre que c'est pas ce que l'on fait le plus lorsqu'on utilise Subversion

D'après ce que j'en sais, la solution SVN + TSVN est une des plus utilisées par les développeursLabVIEW. Cependant il semble que Git et Hg qui ne sont pas basés sur le même fonctionnement que SVN aient des avantages, mais là je laisse des personnes plus qualifiées s'exprimer car je n'ai jamais testé.

Dans tout les cas, j'encourage tout le monde à utiliser se genre d'outils. C'est essentiel pour assurer un développement de qualité dans la durée.

Cordialement,

Olivier

[jihef]

Bonsoir,

Sur le projet qu'on a développé, on a utilisé SVN (côté infrastructure on n'a pas eu trop de problèmes car c'était déjà un des choix de ma société).

Par ailleurs on a mis en œuvre un couplage entre notre outil de suivi de modification et SVN (lors des commits, le message mis dans SVN référence la fiche de modification et la fiche de modification est mise à jour automatiquement avec les traces du commit via des scripts SVN). Un plus pour la traçabilité.

A l’usage, un gros avantage s’est révélé être la gestion des branches. Sur notre projet on a géré 3 versions en parallèle : une version « principale » en préparation sur le tronc où on avait des chantiers de modifications suite à des évolutions + deux versions déjà en production sur lesquelles il fallait pouvoir faire des corrections rapidement si nécessaire. Avec au final la nécessité de refaire re-converger ces trois versions pour la version finale. Pour ce genre de situation l’utilisation de SVN + l’utilisation outil de diff graphique sur les VI intégré à SVN rendent bien des services.

Les quelques difficultés qu'on a eues sont plutôt liées à LabVIEW qu'à SVN et on les aurait eues avec n'importe système de gestion de version. Elles sont liées au fait qu’on utilisait LabVIEW 8.5.1 et qu’il arrive que des VI soient recompilés même si on ne les a pas modifiés. Du coup ces fichiers sont considérés comme ayant été modifiés par SVN. On peut s’en sortir avec une bonne méthode de travail mais ce n’est pas très confortable. Ce problème n’existe plus avec les dernières versions de LabVIEW.

Donc au final, retour très positif. En plus l’interface de TortoiseSVN est bien pratique sous Windows .

Quand on a essayé, on n’imagine plus de s’en passer… et c’est une bonne chose !

Pas d’expérience sur d’autres outils de gestion de version.

Cordialement

Jean-François (alias Jihef)

[Marie_Remondière]

Bonjour,

Pour info, je me suis rendue compte qu'on manquait d'une catégorie "partage d'expérience" pour ce genre de discussion alors j'en ai créé une et je vous ai mis dedans

C'est tout. Bonne discussion !

Marie

[DaHelmut]

Bonjour,

Merci à tous pour ces informations. Je pense aussi me tourner vers SVN + TSVN, l'installation a été très simple et l'utilisation l'est tout autant.

Le seul soucis majeur c'est la création des reps qui me pose problème, étant donné qu'il faut obligatoirement passer par l'administrateur réseau dans le cas de mon entreprise...A voir.

Jihef tu as dis :

"Par ailleurs on a mis en œuvre un couplage entre notre outil de suivi de modification et SVN (lors des commits, le message mis dans SVN référence la fiche de modification et la fiche de modification est mise à jour automatiquement avec les traces du commit via des scripts SVN). Un plus pour la traçabilité."

Est-ce que ce genre de script est facile à créer / mettre en oeuvre ? Ca risque d'intéresser mon responsable puisqu'on a aussi un fichier de modification par projet...

Encore merci pour vos réponses.

Cordialement,

[jihef · Accepted solution]

Bonjour,

Sur les détails de la mise en oeuvre je n'ai pas toutes les informations.

Toutefois, le principe est le suivant : dans le commentaire du commit l'utilisateur met, avec une syntaxe reconnaissable, la référence à la fiche de modification.

Le script SVN récupère cette information (il refuse même de faire le commit si elle est absente !) et s'en sert pour faire les commandes d'update qui vont bien à destination de la base SGBD contenant les descriptions des fiches de modifications.

Cordialement.

--

Jean-François

[Olivier-JOURDAN]

DaHelmut wrote:

Le seul soucis majeur c'est la création des reps qui me pose problème, étant donné qu'il faut obligatoirement passer par l'administrateur réseau dans le cas de mon entreprise...A voir.

Quelle méthode d'accès à tes repositories utilises-tu ? "Http" ou "file" ?

Si "File" à l'avantage de la simplicité (excepté les éventuels droits d'accès au disque), http à l'avantage de permettre d'avoir une interface de création de repository accessible et protégée par mot de passe. La mise en oeuvre d'un tel accès résoudrait peut-être ton problème de droit. De plus, cela permet de donner l'accès à ton repository en dehors de ton intranet. Il m'arrive sur certains projets de partager l'accès avec mon client et ainsi faciliter la mise à jour et la modification du code tout en gardant une traçabilité plus qu'utile.

[Olivier-JOURDAN]

jihef wrote:

Les quelques difficultés qu'on a eues sont plutôt liées à LabVIEW qu'à SVN et on les aurait eues avec n'importe système de gestion de version. Elles sont liées au fait qu’on utilisait LabVIEW 8.5.1 et qu’il arrive que des VI soient recompilés même si on ne les a pas modifiés. Du coup ces fichiers sont considérés comme ayant été modifiés par SVN. On peut s’en sortir avec une bonne méthode de travail mais ce n’est pas très confortable. Ce problème n’existe plus avec les dernières versions de LabVIEW.

Salut jihef, je pense que tu parles de la séparation de l'option de séparation du code compilé pour résoudre ce problème. J'attire l'attention de chacun sur la modification de comportement de cette option depuis LV2012 --> https://decibel.ni.com/content/thread/15606?tstart=0

Cordialement,

Olivier

[jihef]

Salut Olivier,

J'étais passé à côté de ce "détail". Pour des raisons de "stabilité" de notre applicatif on est resté en LabVIEW 8.5.1. J'ai continué à me tenir informé des dernières versions de LabVIEW et à travailler avec, mais j'étais passé à côté de cette "caractéristique" de LabVIEW 2012.

Cela ressemble quand même à un bug LabVIEW, non ? Réglé par un forçage de recompile avec marquage des source des VI comme étant modifiés, si je comprends bien ? Cela risque d'être une solution définitive...

Concvernant la gestion de version, cela veut dire qu'il vaut mieux, quand on peut, commencer par modifier le typedef, faire un commit en indiquant dans le commentaire qu'on a modifié que le CTL (promis, juré) même si des VI qui le référencent sont commités aussi...

En tous cas, merci pour l'information.

Cordialement,

Jean-François

[Olivier-JOURDAN]

Y a pas réellement de méthodes satisfaisantes, à ma connaissance, pour gérer ce problème. Aux choix :

• Si le ctl est appelé dans de nombreuses parties du code, je modifie le CTL et les VIs associés à la modification en prenant garde de ne pas faire un "save all", je sauve les VI modifié en mettant commentaire adéquat. Après je fais un "save all" plus commit avec un commentaire "recompile". En cas de conflit, on sait garder la bonne version en regardant le log
• Si je travaille sur un module bien défini je travaille "normalement en faisant des "save all" puis au commit je ne commit que le dossier contenant le code sur lequel je travail. Les autres modifs sont commitée en "recompile"

il existe surement d'autres manières de faire, mais celles-ci permettent de bien vivre avec le fonctionnement de LabVIEW.