Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Comportement - proposition

Quand on modifie une "définition de type", on a a les 3 possibilités suivantes :

 

Save

Defer decision

Cancel (Cancel the close operation)

 

et si on a fait une erreur et que l'on désire "annuler" la modification ..... on fait quoi ?

 

si on a modifié une définition de type un rien complexe, avec plusieurs modifications,

on peut très vite se retrouver dans le cas ou on ne sait plus qu'elle était exactement la définition de départ.

Dans ce cas, il n'est plus possible de faire la "modification inverse" .... et c'est le cul de sac !

 

Peut-être alors choisir "Defer decision" ??? et fermer le projet en choisissant un "save" sélectif ?

Mais si on a fait d'autres mofifs (des mofifs de code) ... alors on ne sait pas (difficilement) savoir quels sont les VIs à sauver et ceux qui ne le doivent pas.

Et si certains VIs contiennent des modifs de code ET aussi cette fameuse définition de type (!!!!)

 

Ce serait très pratique d'avoir en plus la possibilité deCancel Changes

 

Qu'en pensez-vous ? Avez vous déjà rencontré ce problème

 

 

 

 

 

0 Compliments
Message 1 sur 63
4 624 Visites

salut je fais un revert (via LabVIEW), sinon j'ai un SVN et je fais aussi un

revert Revient à une version donnée d'une ressource. Les modifications locales sont écrasées.

 

Logiciel de gestion de code source :

https://decibel.ni.com/content/docs/DOC-30198

Utilisation du contrôle de source (pour LabVIEW et autres...)

 

Le contrôle du code source est l'un des aspects les plus élémentaires (mais aussi les plus négligés) du développement logiciel professionnel. Un système de contrôle du code source fournit les versions des fichiers pour l'ensemble de votre projet. Le contrôle du code source permet à plusieurs développeurs de vérifier l'arborescence source d'un projet et d'éviter aux ingénieurs d'écraser le travail des autres.

 

chez MESULOG : SVN et TortoiseSVN

 

A+

Message 2 sur 63
4 610 Visites

Bonjour Luc,

 

Le contrôle et la gestion des codes ...

 

négligé ? pas de mon côté ... j'archive soigneusement mes versions avec un numéro, une date et éventuellement un commentaire.

 

simplement parcequ'on est jamais à l'abris d'un gros soucis .... et qu'à ce moment on est bien content de retrouver la version " t-1 ".

 

Je n'utilise pas de soft dédié pour cela, je le fais "en manuel" (ceci dit, je développe seul)

 

On fait une "modif" ... et d'un seul coup, plus rien ne fonctionne ... cela m'a déjà sauvé la vie plus d'une fois.

 

Pour les modifs dans une définition de type ....

 

je viens d'y penser .... CTRL-Z ... tout simplement ... !

 

Cela en cours de modifs du type def ... sinon, "après", si on a fait  trop de dégâts .... retrour à une version antérieure.

 

Perso, je fais un archivage dès qu'il y a une modifs "substentielle" ... et toujours en fin de session de travail, soit au minimum une fois par jour.

0 Compliments
Message 3 sur 63
4 604 Visites

Han... Archivage manuel...

 

Au-delà de toutes les fonctionnalités précieuses du control de code source, la taille devient vite un problème. Et faire un zip tous les jours pour différencier les versions jour après jour n'est pas maintenable et prend du temps.

 

Si la taille d'un projet est S :

N versions archivées manuellement => Taille totale sur le disque en O(S*N)

N versions sous SCC (Source Code Control) => Taille totale sur le disque (du serveur SCC) en O(α*N) où α est un facteur de poids relatif au nombre de modifications binaires entre 2 versions successives. α est donc très inférieur à S.

 

Et pour la simplicité, faire un clic droit -> Commit sur un dossier ou sur un projet LabVIEW et c'est fini... 🙂

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

Message 4 sur 63
4 597 Visites

ok ...

 

oui, suis d'accord, c'est préhistorique.

 

bon ... je vais me faire un "quick drop" qui me fera tout ça avec un "CTRL-key"

 

la perte de temps : Je programme pour occuper mes soirées. (et surtout par passion)

J'ai quitté le monde du "toujours plus vite" par choix philo-existentiel.

 

la mémoire : mon projet zippé fait 3,5 Mo

une centaine de versions précédentes me prend un maximum de 350Mo ... et j'ai 2To sur le dur principal.

 

des précieuses fonctionnalités : du moment que j'ai mes versions précédentes sauvegardées ...je n'ai, jusqu'à présent, rencontré aucun "besoins" au delà de ça.

Je n'ai pas encore eu besoin de fonctionnalités bien "spéciales" (le jour où ce sera le cas, alors ok)

 

Bon ....

 

ceci dit, je comprends parfaitement ton point de vue. (à 200%)

 

Tu développes dans un environnement astreint à des contraintes précises, moi pas.

 

Tu développes en professionnel, pour le monde scientifique, industriel, etc ...

moi, je bidouille sur mon foutu jeu d'échecs (qui à fait la "une" tout de même  Smiley heureux )

 

Nos univers sont totalement différents (et nos besoins aussi)

 

Moi, je bricole des prototypes dans le fond de mon garage,

toi, tu bosses dans le Team McLaren.  Smiley heureux

 

 

0 Compliments
Message 5 sur 63
4 593 Visites

Salut,

 

L'archivage ce n'est pas de la gestion de code source.

C'est de l'archivage (sauvegarde)

 

Ouadji, je te promets que si jamais tu mets le nez dans un outil de SCC (type SVN), plus jamais tu ne feras machine arrière pour revenir à une solution manuelle.

C'est indispensable, quelle que soit la taille du code.

 

Mathieu


Message 6 sur 63
4 551 Visites