LUGE 2022.4 - Présentation "Fichier projet LabVIEW et gestion de version"

[Nicolas_Bats]

Bonjour à tous les LUGEistes,

Voici un petit message pour prendre le temps de répondre aux questions qui n'ont pas pu être posées pendant la dernière présentation que j'ai faite au LUGE 2022.4, pour rappel le sujet de cette dernière était "Fichier projet LabVIEW et gestion de version". Je me suis basé sur les échanges dans le chat mais si vous avez d'autres questions n'hésitez pas.

Les slides de la présentation viendront prochainement !

Pas de code d'exemple.

Au plaisir de continuer à échanger,

Nicolas

[Nicolas_Bats]

---

FAVIER Pierre
pourra t on un jour ouvrir les VI en textuel a l'image du .NET avec les .xaml?

---

Seul NI peut répondre à cette question mais ça serait une bonne idée !

ADK
Ouvrir le projet en XML permet de connaitre la version de LV utilisé.

---

Oui mais cela ne veut pas dire que tous les VI dans le projet sont dans cette version de LabVIEW. Il vaut mieux regarder la version de chaque VI.

Amaury LAURENT
NB : les lvlib et lvclass sont sur le même modèle

---

J'avais quelques slides pour comparer VI / LIB / CLASS mais Luc était trop pressant sur le timing. Je mettrai peut-être du contenu additionnel dans les slides de la présentation au moment de partager.

Cyril Gambini
Pourquoi ? a part 'etre plus propre' dans mon commit (ce qui est tres relatif)

---

Être plus propre dans son travail est déjà une raison suffisante ^^ mais réduire la taille et le nombre de commit permet de simplifier la lecture de l'historique GIT et d'accélérer la résolution de conflits ou de problème suite à des merge.

Amaury LAURENT
n'y a t'il pas une somme de contrôle dans le lvproj ?

---

Pas à ma conaissance. Si on ouvre un projet vide on a ca :

<?xml version='1.0' encoding='UTF-8'?>
<Project Type="Project" LVVersion="15008000">
<Property Name="NI.LV.All.SourceOnly" Type="Bool">true</Property>
<Item Name="My Computer" Type="My Computer">
<Property Name="server.app.propertiesEnabled" Type="Bool">true</Property>
<Property Name="server.control.propertiesEnabled" Type="Bool">true</Property>
<Property Name="server.tcp.enabled" Type="Bool">false</Property>
<Property Name="server.tcp.port" Type="Int">0</Property>
<Property Name="server.tcp.serviceName" Type="Str">My Computer/VI Server</Property>
<Property Name="server.tcp.serviceName.default" Type="Str">My Computer/VI Server</Property>
<Property Name="server.vi.callsEnabled" Type="Bool">true</Property>
<Property Name="server.vi.propertiesEnabled" Type="Bool">true</Property>
<Property Name="specify.custom.address" Type="Bool">false</Property>
<Item Name="Dependencies" Type="Dependencies"/>
<Item Name="Build Specifications" Type="Build"/>
</Item>
</Project>

Matthias Baudot
je trouve ça cool. Je dois avouer que je fais souvent ce travail de cleaning directement dans mon client GIT (GitFork) en faisant le Staging des sections du LVPROJ qui m'intéressent uniquement.

---

Avant je le faisais à la main aussi mais c'est devenu trop fastidieux et impossible avec les morceaux de code FPGA très longs (milliers de caractères par ligne) il fallait scroller en permanence.

---

Matthias Baudot
Je verrai bien ton outil appelé directement avec une Custom Command dans Git Fork

---

Dans une optique d'automatisation je suis d'accord que ce travail de nettoyage devrait être appelé (mais pas fait) par les outils GIT. Peut-être à refondre en un script ...

J'aime bien aussi conserver la possibilité de lancer ce ménage manuellement pour voir les modifications dans le fichier projet avant de lancer le commit.

Cyril Gambini
C'est pas la fin deja ?

---

Va lire le lièvre et la tortue Cyril ^^

---

FAVIER Pierre

peut on utiliser ce programme pour pour d'autres gestionnaires de sourcing geres par labview (TFS) ou non gerés (SVN)

Mathieu Reyrolle
yes, la problématique est la même quel que soit l'outil de versionning.

---

Oui le toolkit modifie le projet LabVIEW donc c'est indépendant du gestionnaire de code source.

---

Amaury LAURENT
pas de risque de corrompre le projet du coup ?

---

Je n'ai pas rencontré de problème jusqu'à présent et l'utilisation d'un script pour faire le ménage est mieux que de le faire a la main (il m'est arrivé d'oublier des lignes quand je faisais le ménage à la main) mais si le risque existe. A voir à l'avenir peut-être qu'en utilisant un item de projet d'un nouveau type ça arrivera. Ca vaudrait le coup de poser la question à NI.

Après la philosophie du script plutôt conservatrice, c'est : "Je garde tout et j'enlève ce qui ne m'intéresse pas" et pas "j'enlève tout et je garde ce qui m'intéresse". Si a l'usage je rencontre des nouvelles balises XML à enlever je modifie mon script pour l'améliorer.

Maxime Renaud
ESt ce qu'on ne pourrait pas le gérer simpmement avec Hook Script par exemple pour faire ce nettoyage automatiquement ?

Mathieu Reyrolle
tu pourrais te retrouver avec un fichier projet vu comme modifié, traiter les modifications, et se retrouver sans modifs à livrer... Haha !

Maxime Renaud
si tu n'as que ton projet à Commit, tu peux te poser la question de ton commit

---

J'imagine que le commit serait simplement annulé.

Effectivement le seul cas ou ca pourrait se produire c'est si je commit uniquement le projet (sinon il y aura des VI et autres fichiers dans le commit). Et si je commit uniquement le fichier projet c'est qu'en général j'ai volontairement changé quelque chose dedans.

Anthony ASARO
sympa le sponsor Amazon

---

Haha c'est juste une petite blague pour les Questions & Réponses mais ça marche aussi avec le "dit Siri" et le "OK Google". Je ferai tourner les fournisseurs sur les prochaines présentations 😉

[CyGa]

Cyril Gambini
Pourquoi ? a part 'etre plus propre' dans mon commit (ce qui est tres relatif)

Être plus propre dans son travail est déjà une raison suffisante ^^ mais réduire la taille et le nombre de commit permet de simplifier la lecture de l'historique GIT et d'accélérer la résolution de conflits ou de problème suite à des merge.

=> Merci du conseil. Mais mon point n'est pas vraiment la.

Le projet est source de conflits de toute façon puisqu'il est central et mis à jour par le travail de tous les développeurs.

Il est général de la responsabilité d'un seul développeur de le maintenir à jour ou bien de le cibler dans un commit particulier relié à une issue.

Il se concentre en un seul fichier, qui n'est pas censé être lu par l'humain (il pourrait tout aussi bien être stocké en binaire qu'on ne ferait pas la différence). Il ne doit donc pas être l'objet d'un commit en soit.

Si on suit ce raisonnement, est-il nécessaire de 'nettoyer' son contenu ?

Attention à l'emphase sur 'nécessaire', le travail présenté est tout à fait intéressant selon moi. Je m'interroge sur la nécessité de le faire seulement. 

Va lire le lièvre et la tortue Cyril ^^

=> Je te remercie de partager avec nous tous tes références littéraires.

[Nicolas_Bats]

---

Le projet est source de conflits de toute façon puisqu'il est central et mis à jour par le travail de tous les développeurs.

---

Si tu commit tout le fichier en l'état oui c'est source de conflit mais si tu commit uniquement "l'information utile" alors non il y a très peu de conflits. Vu que c'est un fichier texte les modifications sont gérées automatiquement par le système de SCC même si effectuées par plusieurs développeurs.

En développement textuel un fichier .c ou autre est central et peut être mis à jour par tous les développeurs sans problème.

Il est général de la responsabilité d'un seul développeur de le maintenir à jour

---

Ca c'est un contournement mis en place du fait dont LabVIEW gère le contenu du fichier projet. Mais l'idée de la présentation c'est justement de s'affranchir de cette règle que je ne trouve pas justifiée, tout le monde doit pouvoir commiter un changement sur le projet LabVIEW si c'est justifié.

---

ou bien de le cibler dans un commit particulier relié à une issue.

---

Chez moi aussi un commit est presque toujours relié à une issue mais un commit peut contenir un changement sur le fichier projet et aussi d'autres fichiers.

---

Il se concentre en un seul fichier, qui n'est pas censé être lu par l'humain (il pourrait tout aussi bien être stocké en binaire qu'on ne ferait pas la différence).

---

Pourquoi est-ce qu'il n'est pas censé être lu par l'humain ? Et les systèmes de SCC ? Moi je trouve ça très bien qu'il puisse être lu par les systèmes de SCC pour justement gérer automatiquement les additions / deletions.

Si le fichier projet était binaire ça serait préjudiciable d'un point de vue gestion de versions. Je trouve ça dommage que les VI soient des fichiers binaires (vu du client GIT).

---

Il ne doit donc pas être l'objet d'un commit en soit.

---

Si on prend l'exemple d'un issue "Le logiciel est déployable sous la forme d'un exécutable". Le changement dans le code source se traduit uniquement par la création d'une spécification de construction dans le fichier projet. Je commit les changements et uniquement le fichier projet est commité (préférablement uniquement la partie du XML qui concerne la spécification de construction pas tout le bazar autour).

Si on suit ce raisonnement, est-il nécessaire de 'nettoyer' son contenu ?

Attention à l'emphase sur 'nécessaire', le travail présenté est tout à fait intéressant selon moi. Je m'interroge sur la nécessité de le faire seulement.

---

Nécessaire non, je dis juste que de mon point de vue c'est mieux ^^ en tout cas cette façon de travailler me semble plus robuste et productive.