Discussion :

[Lo²]

Bonjour à tous,

Nous sommes en train de demander de passer du GDS à Git du fait d'un problème régulier lors de la réintégration d'un même élément modifié par plusieurs développeurs en même temps.

Première question :
Dans la configuration multi-développeurs, comment travaillez-vous ?
- une même branche par dév ?
- une branche par dév ?
- autrement ?

Deuxième question :
Sur le GDS, avez-vous rencontré des problèmes de réintégration : perte de code ou autre ?
Si oui, avez-vous réussi à cerner la cause et donc à réduire ces problèmes ?

Troisième question :
Pour ceux qui sont passés du GDS à Git, votre avis m'intéresse ?
Pas d'avis pro-Git ou anti-GDS

[frenchsting]

Bonjour Lo²,

On utilise le GDS. Les extractions sont en mode exclusif. Un élément ne peut être extrait que par une personne.

Suivant le projet :
Soit on n'a qu'une seule version (petit projet = un seul développeur va travailler dessus ou c'est outil en interne).
Soit c'est un projet multiversions : typiquement le projet déployé chez les clients. On a une branche par version. Tout simplement.


Le serveur GDS ne doit pas être une récup de fond de tiroir. Il doit être un minimum dimensionné en disque, en RAM et en processeur.

J'avoue ne pas avoir eu d'énorme souci avec pendant ma carrière. Des pertes, oui, mais pas "énorme". Quelques fichiers sur plusieurs décennies d'utilisation. Et on a toujours réussi à se débrouiller pour retrouver les pertes. Je pense que ça va aussi avec ma remarque précédente concernant le serveur.

Le passage à GIT, on s'est posé la question. Mais en fait, GIT est prévu pour du fichier texte et la solution PCSOFT (en gros des binaires encodée en base 64) ne me semble pas intéressante (surtout si on a des sources de plusieurs Go).

[Lo²]

Merci pour ta réponse @frenchsting,

Lorsque j'étais seul j'avais ma projet maître pour les dev en cours et mes branches par version pour le débuggage.
Depuis, changement de boîte et plusieurs à développer sur les mêmes projets mais nous rencontrons pas mal de problème lorsqu'un élément est extrait par plusieurs personnes à la fois.

En mode exclusif, ça limite les problèmes mais QUID des développement qui se croisent pour modifier le même élément ? Attendre que l'élément soit libéré n'est pas top je trouve.
Est-ce que de créer une branche par développement pour ensuite réintégrer le tout dans le maître te semble viable ?

[frenchsting]

Et bien pour te répondre, dans mon ancienne boîte, on avait une fenêtre que tout le monde voulait (= régulièrement au moins 2 personnes la voulaient). Cette fenêtre était énorme (le fichier wdw dépassait allégrement les 15 Mo). Et chacun attendait son tour pour l'avoir... C'est la seule solution pour que le GDS soit efficace (je trouve). Je suis certain que tout GIT qu'il est, le souci sera le même (encore pire ?) en cas de d'accès simultané.

Faire du multi branche et fusionner. Dans l'idée, pourquoi pas... Mais est-ce qu'il n'y aura pas des erreurs / bugs remontés. Le truc tout bête : dans une fenêtre, par ex (trivial, je sais), un dév fait sUtilisateur est chaine. Un autre dans sa branche fait sUtilisateur est chaine UNICODE. Que va t'il se passer lors de la fusion. Pire : il va falloir éplucher le code pour savoir si les instruction sont plutôt compatibles ANSI ou UNICODE...

[wd_newbie]

De mon côté, le GDS fait assez bien le travail.

Les soucis que je rencontre régulièrement sont lors de copie / remplacement de fenêtre : si je supprime la FEN_Fenetre_1 --> synchro avec le GDS et que je recrée une nouvelle FEN_Fenetre_1, ça part en vrille ...
Le GDS ne reprend pas la fenêtre, si je veux forcer l'intégration : elle existe déjà , etc.

Sinon, à part dans ces cas, pas souçis.

[hpascal]

Les soucis que je rencontre régulièrement sont lors de copie / remplacement de fenêtre : si je supprime la FEN_Fenetre_1 --> synchro avec le GDS et que je recrée une nouvelle FEN_Fenetre_1, ça part en vrille ...
Le GDS ne reprend pas la fenêtre, si je veux forcer l'intégration : elle existe déjà , etc.

Salut
Pour éviter ce problème, après une suppression, il faut ouvrir l'administrateur du GDS, faire un clic droit sur le répertoire du projet, puis Propriétés.
Il y a un onglet "Éléments supprimés" et un bouton pour les purger.
Tant que ce n'est pas fait, utiliser le même nom d'objet c'est des problèmes assurés !

Concernant le GDS nous travaillons à 7 développeurs et il y a régulièrement des soucis (perte de code par exemple), par forcément liés au GDS mais plus à des problèmes de cache de Windev.

Parfois, certainement à cause d'un problème de cache, le code affiché à l'écran ne contient pas les modifs récentes d'un autre développeur.
Du coup, on le modifie, on le réintègre et ... du code a été perdu.

Un conseil du ST : Fermer tous les éléments ouverts avant de récupérer des objets du GDS.

[frenchsting]

Bonjour,

Nous avions beau être pas mal en dév à travailler sur le même projet, on n'a que rarement eu de déboires avec le GDS.

Pour l'histoire des suppressions "parasites", dans toutes les boîtes dans lesquelles j'ai travaillées, on avait obligation (tout du moins, on se donnait cette obligation) de nommer les fenêtres avec un "vrai" nom dès la création. La probabilité de conflit devient alors exceptionnelle et est résolue comme le précise hpascal.

[Lo²]

Salut
Un conseil du ST : Fermer tous les éléments ouverts avant de récupérer des objets du GDS.

Salut,

Est-ce que ce conseil a réduit les problèmes ?

[frenchsting]

J'ai une question : le serveur du GDS est (était) il bien dimensionné (et le réseau "performant") ?

[Lo²]

J'ai une question : le serveur du GDS est (était) il bien dimensionné (et le réseau "performant") ?

J'ai envie de dire que oui car le GDS est hébergé sur le cloud PCSoft et de la fibre.

[hpascal]

Salut,

Est-ce que ce conseil a réduit les problèmes ?

Je ne sais pas trop. Je ne sais même pas si tout le monde applique ce conseil.
Mais ces derniers temps j'entends moins de problèmes.

[Lo²]

ok merci pour le retour @hpascal

[wd_newbie]

et question bête,mais ... il est possible de travailler en paralèlle avec le GDS et Git , histoire d'avoir ceinture et bretelles ?

[frenchsting]

Bonjour,

Je ne pense pas que cela soit possible.

Mais il faut surtout faire une sauvegarde de base du GDS régulièrement.

[fred_malette]

Bonjour à tous,

Nous sommes en train de demander de passer du GDS à Git du fait d'un problème régulier lors de la réintégration d'un même élément modifié par plusieurs développeurs en même temps.

Première question :
Dans la configuration multi-développeurs, comment travaillez-vous ?
- une même branche par dév ?
- une branche par dév ?
- autrement ?

Deuxième question :
Sur le GDS, avez-vous rencontré des problèmes de réintégration : perte de code ou autre ?
Si oui, avez-vous réussi à cerner la cause et donc à réduire ces problèmes ?

Troisième question :
Pour ceux qui sont passés du GDS à Git, votre avis m'intéresse ?
Pas d'avis pro-Git ou anti-GDS

Bonjour !

Utilisateur du GDS depuis des années, je le subis avec plus ou moins de bonheur. Je vais essayer de ne pas faire dans le anti-gds / pro-git basique, mais voici quelques retours d'expérience :
Je n'ai pas le souvenir d'avoir perdu du code, mais en revanche :
1) La gestion des branches est totalement buggée. Nous nous en servons uniquement pour archiver les versions antérieures de notre solution. Nous aimerions pouvoir créer davantage de branches (par exemple une branche par développeur et/ou par fonctionnalité majeure en cours de dév) mais le GDS ne tient tout simplement pas la charge. Les reports de modification inter branches sont extrêmement chaotiques, il faut faire très attention, procéder avec beaucoup de méthode, et ne pas hésiter à recommencer les opérations en cas de plantage (ce qui arrive souvent).
2) L'outil est, chez nous, très instable. On se retrouve régulièrement avec des erreurs exotiques lors de la récupération des modifications d'un projet. Certains fichiers restent extraits en mode "fantôme", alors qu'ils ont été réintégrés.
3) C'est lent, très lent, même avec un serveur performant.
4) D'après mon expérience, le GDS a beaucoup de mal dès que l'on a à la fois des composants internes partagés entre différents projets, et plusieurs branches. Je pense que pas mal de nos soucis viennent de là, et je crois que d'autres utilisateurs de ce forum sont arrivés à la même conclusion (c'est dommage, car les branches, c'est très pratique, et les composants internes aussi !)

Je n'ai pas encore eu l'opportunité de tester Git dans un environnement Windev et je crains que l'intégration ne soit compliquée (en raison du format propriétaire de leurs fichiers sources).
En revanche je l'utilise depuis longtemps sur des projets hors Windev et c'est un outil que j'apprécie. La gestion des branches est efficace, l'outil est très léger (les opérations sont ultra rapides en comparaison avec le GDS), et quel bonheur de ne plus avoir à s'embêter à extraire les fichiers sur lesquels on bosse ! La réintégration et la fusion des modifications se passe toujours très bien, à condition bien sûr de gérer manuellement les conflits occasionnels (qui sont normalement assez rares si le code est bien structuré et que les développeurs ont été formés un minimum aux bonnes pratiques).

Je ne pense pas que l'on puisse faire cohabiter GIT et GDS ensemble.

[kunnskap]

(qui sont normalement assez rares si le code est bien structuré et que les développeurs ont été formés un minimum aux bonnes pratiques).

AH, voilà le hic
Cette jolie phrase est malheureusement trop rare en Windev.
Le GDS n'est en effet pas un modèle de stabilité, les branches sont cassées, les merges j'ai même jamais essayé (courageux, mais pas téméraire quand même n'abusons pas)
Git? J'y ai même pas songé avec Windev et je doute que ça fasse des miracles vu le format propriétaire.

[Lo²]

AH, voilà le hic
Cette jolie phrase est malheureusement trop rare en Windev.

Comme si c'était spécifique à Windev

[fred_malette]

Comme si c'était spécifique à Windev

Non tu as raison, ce problème n'est pas spécifique à Windev, mais peut être plus prononcé que sur d'autres technologies.
En même temps c'est un peu normal : PC-soft axe une bonne partie de sa communication sur le fait que leurs outils permettent de construire des applications très rapidement et avec très peu de code. Et c'est (plutôt) vrai : du coup, cela a attiré pas mal de développeurs non professionnels n'ayant pas été formés. Ce n'est pas une critique, car c'est à mon sens l'un des avantages de Windev : un non-développeur peut effectivement construire une petite application de gestion sans avoir de connaissances poussées en développement.
Mais selon moi le revers de la médaille est que les outils de l'écosystème Windev ont parfois tendance à encourager un certain amateurisme (ou en tout cas à l'autoriser, ce qui peut aussi être vu comme un atout, j'en conviens...).

[kunnskap]

Non tu as raison, ce problème n'est pas spécifique à Windev, mais peut être plus prononcé que sur d'autres technologies.
En même temps c'est un peu normal : PC-soft axe une bonne partie de sa communication sur le fait que leurs outils permettent de construire des applications très rapidement et avec très peu de code. Et c'est (plutôt) vrai : du coup, cela a attiré pas mal de développeurs non professionnels n'ayant pas été formés. Ce n'est pas une critique, car c'est à mon sens l'un des avantages de Windev : un non-développeur peut effectivement construire une petite application de gestion sans avoir de connaissances poussées en développement.
Mais selon moi le revers de la médaille est que les outils de l'écosystème Windev ont parfois tendance à encourager un certain amateurisme (ou en tout cas à l'autoriser, ce qui peut aussi être vu comme un atout, j'en conviens...).

C'est tout à fait ça!
Ce n'est en effet pas spécifique à Windev, mais ça y est quasiment la norme comparé à d'autres langages.
Déjà que dans les autres, on ne croise pas toujours ceux qui songent à la qualité de leur code, mais dans Windev c'est 100 fois pire.

Permettre l'extraction multiple d'une fenêtre où on a enfermé l'IHM, le code métier et l'accès à la base, ça va être une épreuve de faire le merge ensuite. Si le GDS tiens jusque là, bien sûr