Discussion :

[fred_malette]

Bonjour,

Je m'arrache les cheveux avec le GDS et j'aimerais avoir vos lumières car il est possible que je ne fasse pas les choses comme il faut, ce qui expliquerait mes problèmes.

Le contexte :
Une branche de développement, qui contient différents projets indépendants, et divers composants internes qui sont partagés dans ces différents projets.
Une branche de production qui a exactement la même structure, et dans laquelle on reporte régulièrement des modifications depuis la branche de développement.

L'utilisation de composants internes est relativement récente.

Avant que nous n'utilisions des composants internes, le système fonctionnait plutôt bien, malgré quelques bugs occasionnels.

Mais depuis que nous avons pas mal de composants internes, c'est la Bérézina : le report de modifications depuis la branche de développement vers la branche de production est devenu un enfer, dès lors que l'on touche aux composants internes.
Windev détecte bien les modifications, propose le report, dit qu'il le fait et ... en fait il ne fait rien du tout, les composants internes de la branche de production sont inchangés.
J'en suis réduit à reporter mes modifications à la main, ce qui, en plus d'être fastidieux, est dangereux.

Je pose donc la question : certains ici arrivent-ils à gérer des branches de taille (un peu) conséquente (quelques dizaines de gros projets utilisant une bonne dizaine de composants internes partagés) avec le GDS ?
Y a-t-il des pièges à éviter, ou des astuces à connaître pour que cela se passe bien ?

Merci pour votre aide et vos retours.

[kunnskap]

J'ai un GDS avec des projets qui partagent des composants internes. Il s'avère que créer une classe à partir d'un fichier de l'analyse d'un composant interne provoque l'ajout de la classe dans le composant, mais ne rend pas la classe dispo pour les projets partageant le composant. D'ailleurs dans le GDS, le fichier de la classe n'est pas partagé.
Il faut en fait créer la classe à la main et y écrire ce que Windev écrirait en cas de génération. Pas top, mais la classe est du coup bien intégrée au composant et partagée dans tous les projets l'utilisant.
Les branches, ca fait un moment que je n'ai plus mis le nez dedans. Il y a plusieurs années, on avait eu des mauvaises surprises; nos développements ne rendent pas absolument nécessaire qu'on s'en serve on a donc renoncé.

Mixer les deux reviendrait pour moi à faire du vaudou
Autant pour les branches c'était gérable et ma fois, ça tournait bien, autant les composants internes....le GDS les digère TRES mal et c'est rien de le dire.

[Lo²]

Bonjour,

J'utilise le GDS régulièrement et en effet, il y a des choses qui fonctionnent mal mais je ne sais pas si c'est à cause de mes projets qui commencent à dater et donc qu'il faudrait faire du ménage dans les fichiers et dossiers du projet ou si c'est lié au GDS.

Déjà je ne comprends pas trop le contexte : plusieurs projets dans une seule branche ? Tu veux dire que tu utilises une arborescence de branche pour plusieurs projets c'est ça ?

Le truc que j'utilise pour limiter les surprises, c'est l'utilisation du suivi de projet pour attribuer des tâches ou incidents à mes modifications, ça limite fortement le traitement du GDS sur les éléments à synchroniser.

Ce qui ne marche plus chez moi, c'est le rapport des modifications d'analyse et ensuite le fichier style qui n'est pas pris en compte, mais il me semble qu'en 26 ça en parle.

[fred_malette]

Bonjour et merci beaucoup pour vos réponses, même si elles ne sont pas forcément très encourageantes car elles semblent confirmer ce que je craignais : branches et composants internes ne font pas bon ménage :-(

J'utilise aussi au maximum le suivi de projet pour rattacher les modifs à des tâches ou des incidents. J'ai déjà constaté par le passé que cela aide beaucoup pour faire du report de modifications d'une branche à l'autre. Cela évite pas mal de bugs ou de problèmes divers avec le GDS. Mais maintenant que nous avons en plus des composants internes, cela ne suffit plus...

A propos du contexte : j'utilise une arborescence de branches de ce type :

GDS
|
|_Branche de production
|        |____ Projet A
|        |____ Projet B
|        |____ Projet C
|
|_Branche de développement
|        |____ Projet A
|        |____ Projet B
|        |____ Projet C
|
|

Rien que de très classique en somme !
Mais en ajoutant des composants internes partagés entre ces projets, le GDS se met à faire régulièrement n'importe quoi.

Si seulement les fichiers sources Windev étaient de simples fichiers textes, tous ces problèmes disparaitraient, mais ce n'est pas pour demain je crois

[kunnskap]

Il existe une option pour les convertir en fichier texte m'enfin, on sens que ça n'est que le début. On est loin d'un simple fichier de code au format texte...
Si les composants partagés le sont sur des projets ne faisant pas partie de la même branche, je sens que le GDS n'aimera pas. Parce que déjà au sein d'une même branche, pas sûr qu'il soit à la fête.
Après c'est le genre de cas ou quand tu rencontres un cas d'erreur il me faudrait des détails précis pour tenter une reproduction. Je n'ai jamais soumis de bug concernant le GDS à PC SOFT.

[fred_malette]

Il existe une option pour les convertir en fichier texte m'enfin, on sens que ça n'est que le début. On est loin d'un simple fichier de code au format texte...

Ça m'intéresse. Même si je ne suis pas sûr de comprendre : le résultat est un fichier texte, mais ce n'est pas un simple fichier texte ? Comment ça ?

Si les composants partagés le sont sur des projets ne faisant pas partie de la même branche, je sens que le GDS n'aimera pas. Parce que déjà au sein d'une même branche, pas sûr qu'il soit à la fête.
Après c'est le genre de cas ou quand tu rencontres un cas d'erreur il me faudrait des détails précis pour tenter une reproduction. Je n'ai jamais soumis de bug concernant le GDS à PC SOFT.

Non, les composants partagés le sont au sein d'une même branche.
Et ils sont reportés sur une autre branche, et partagés de la même façon entre les projets de cette branche (qui sont eux mêmes reportés depuis la branche source).
Sur le papier, c'est très simple et ça n'a rien d'exotique. Et, comme souvent avec Windev, au début ça semble marcher. Mais quand on commence à avoir pas mal de projets et de composants, ça ne tient plus la charge et le GDS se met à faire n'importe quoi.
Dans ces conditions, c'est compliqué d'indiquer la marche à suivre pour reproduire le problème, malheureusement.

[kunnskap]

Je sais que c'est compliqué à documenter
Depuis la version 25 on peut sauver les fichiers de code au format texte, sauf celui du projet il me semble (mais ce sera possible en 26)
Si tu as WD25 tu pourras lancer le projet que j'ai crée que tu peux télécharger ici https://files.anthonylaurito.fr/deve...ormatTexte.zip
Il fournit un exemple simple avec une classe, une fenêtre, une procédure, aux formats binaire et texte pour que tu puisses voir à quoi ça ressemble.
Si tu n'as pas WD25, tu peux quand même le prendre et ouvrir les éléments avec un bloc notes par exemple cParent_Texte.wdc pour voir à quoi ressemble le fichier texte d'une classe assez simple.
Voici une image, au cas ou tu ne peux pas ouvrir le projet, du code que ça représente pour les éléments. Le seul code qui n'apparait pas c'est celui derrière le bouton Ok de la fenêtre mais il fait 2 lignes et se trouve dans FEN_Main_Texte.wdw

[fred_malette]

Très intéressant merci beaucoup !

Cela ouvre des perspectives intéressantes (en particulier pour se passer du GDS et utiliser Git, ou tout autre gestionnaire de sources).
Le côté "pré-version" me fait un peu peur mais je vais creuser.

Merci encore.

[kunnskap]

Et d'ailleurs, j'ai lu quelque part je ne sais plus du tout où, que Windev et Git ne s'entendent encore pas très bien. Je ne l'ai jamais testé donc j'en sais pas plus.

[frenchsting]

@kunnskap,

En fait PCSOFT a fait du git à sa sauce. Comme on part de fichiers binaires, en gros, il envoient des élément encodés en base 64.

[fred_malette]

Merci pour ces infos.

Mais que se passe-t-il si :
- On enregistre systématiquement les fichiers sources au format texte (du moins les fichiers qui peuvent l'être puisqu'apparemment certains ne sont pas (encore ?) compatibles avec ce format) ;
- On supprime le GDS purement et simplement ;
- On utilise Git à la place.

On développe enfin libéré des limitations (et des bugs) du GDS ?

Je pense que ça risque de ne pas marcher et/ou de ne pas être très viable, d'une part à cause des fichiers qui restent stockés en binaire, et d'autre part parce que le GDS est complètement intégré à l'outil de suivi de projets, et que pour le coup c'est une fonctionnalité que je trouve pratique et qui sera perdue si on se passe du GDS.

Mais si certains ont tenté l'aventure, je serais curieux d'avoir leurs retours d'expérience !

[kunnskap]

Par manque de temps je n'ai pas creusé Windev et Git donc j'ai atteins les limites là...je suis aussi intéressé par des retours d'expérience sur la question.

[bruno.a]

Bonjour à tous,

Je rebondis sur vos messages.
J'ai essayé d'utiliser à un moment la fusion GDS sans les tâches => c'est impossible (trop long...)
Suite à vos messages, j'ai mis en place le suivi de projet en base classique actuellement.
Si je veux la passer en CS, la doc parle d'import mais je ne trouve pas. Il existe un autre moyer que de créer la base vierge sur le CS et recopier la classique ?

Ensuite, j'ai fait des tests en créant des taches et en faisant quelques modifs de codes puis réintégration dans le GDS en liant la tâche et en la cloturant. J'ai lancé la fusion en la basant sur les taches et là c'est beaucoup plus rapide en effet quand le laissant mouliner tout le projet.

Mais je suis tombé sur un os. J'ai créé une fenetre et une méthode dans une classe. j'ai réintégré en liant à la tache. Et là surprise quand je fusionne et que je sélectionne la tache, le GDS me dit : rien à fusionner !!
Je suis passer à coté de qq chose ou on ne peut fusionner que des objets existants entre les branches ?

merci pour vos réponses

[Lo²]

Je viens d'avoir le soucis sur une requête (écrite en SQL) modifiée. Pas de différence trouvée au moment du merge

Edit : Pour être certain de mon affirmation, je viens de créer un projet de test pour le GDS et ici, la modification est bien trouvée.
J'en conclus que cela vient de mon projet que je trimbale d'une version de WD à une autre.

D'après vous, quels serez les fichiers à supprimer, histoire de repartir d'un projet propre ?

[frenchsting]

Bonjour,

Solution rapide : supprimer tout le contenu des dosiers historique, CPL,... Et essayer

si ça ne fonctionne pas : tu crées un nouveau projet et tu importes tous tes éléments dedans...

[Lo²]

Merci pour ces différentes solutions.
Je les essaierai pour ma prochaine version d'appli

[bruno.a]

merci

je vais essayer aussi car nous sommes en train de migrer nos projets en 25 donc avec des dossiers tout neuf en local.

[frenchsting]

merci

je vais essayer aussi car nous sommes en train de migrer nos projets en 25 donc avec des dossiers tout neuf en local.

Tu migres à partir de quelle version ?

Attention au boulot post-migration car il y a souvent des "nouvelles" erreurs (IHM et avertissements notamment) car Windev devient plus strict à chaque nouvelle version. Et un gros bon en avant genre 4 versions, ça va vous prendre beaucoup de temps pour corriger tout ça.

J'avoue que je ne suis pas complètement convaincu par la 25...

[bruno.a]

On migre de 24 à 25.
On se garde toujours 1 an avant de passer sur une version de WD.
Normalement ce sont des projets qui seront publiés début Janvier si pas de loup en migration

[Lo²]

Bonjour à tous,

J'ai utilisé les préconisations de @frenchsting et mes modifications de requête ont bien été reportées, donc merci à toi .

Le problème concernant les modifications d'analyse n'a par contre pas été résolu donc j'ai fait une demande auprès du support et là patatra, grosse déconvenue ce jour auprès de PCSOFT :

Le support m'indique que la fusion de l'analyse n'est pas disponible... lol... il s'agit de la nouveauté 75 de Windev 20.
En fait, j'ai retrouvé un mail que j'avais envoyé en 2015 concernant une erreur lors du report d'analyse sur une branche, dans lequel je fais référence à cette nouveauté.
Je n'ai pas réussi à remettre la main sur le PDF mais je dois avoir quelque part la documentation de cette version dans mon bureau mais je suis en télétravail. Donc si quelqu'un a ce fichier ça m'intéresse


Donc ce que j'en déduit, c'est que certaines nouveautés 'disparaissent' entre version :~