Discussion :

[michel.souris]

Bonjour à tous,

Je souhaite avoir vos retours d’expérience sur l'intégration de projet windev dans des gestionnaires de sources autres que le GDS de windev (svn, sourcesafe...)

Alors je sens déjà venir la question : pourquoi pas celui de PCSoft.... ? le choix ne dépend pas de moi, ma responsable ne souhaite pas l'utiliser car elle n'a pas vraiment confiance dans les produits PCSoft (c'est une position qu'on peut discuter mais je ne suis pas décisionnaire...)

N'hésitez pas à me faire part de vos expériences (heureuses ou malheureuses) sur le GDS également.

Merci d'avance,

[Johjo]

Bonjour,

j'ai essayé une fois pour le fun d'utiliser un autre outil pour la gestion des sources et je considère que c'est se compliquer la vie que d'utiliser un autre gestionnaire de source.

Les gestionnaires de sources (autre que GDS) sont très pratiques pour gérer des fichiers de sources au format texte. Dans Windev, il n'y a rien au format texte. Tout est dans un format binaire. Donc, exit la visualisation de l'historique, la comparaison et la fusion des éléments.

Pour passer outre à cela, j'avais songé à utiliser l'outil permettant de comparer deux éléments windev, mais s'il fonctionne pour comparer, le fait de fusionner des éléments avec ajoute des retours chariots de manière aléatoire dans le code résultant.

Bref, je vous déconseille d'utiliser autre chose que le GDS pour gérer des projets Windev. Même s'il n'est pas parfait et manque parfois de souplesse, ces fonctionnalités sont à mon avis primordiales pour un gestionnaire de source.

J'espère que mon expérience vous aidera.

Cordialement.

[laurent30s]

le choix ne dépend pas de moi, ma responsable ne souhaite pas l'utiliser car elle n'a pas vraiment confiance dans les produits PCSoft

Sans vouloir polémiquer, on "n'a pas vraiment confiance dans les produits PCSoft" mais on utilise les produits PCSoft pour développer ?????

Une petite citation de Villeret dans le diner de con (juste pour l'humour)
Houuuuu, alors ça c'est très tordu, mais bougrement intelligent...

[michel.souris]

Sans vouloir polémiquer, on "n'a pas vraiment confiance dans les produits PCSoft" mais on utilise les produits PCSoft pour développer ?????

Une petite citation de Villeret dans le diner de con (juste pour l'humour)
Houuuuu, alors ça c'est très tordu, mais bougrement intelligent...

"On" ne maîtrise pas toujours l'historique d'un produit et il faut régulièrement assumer les choix de nos prédécesseurs. "On" a juste un soft développé en Windev dans une gamme basée sur d'autres technos.... pour la petite histoire !

Mais merci pour ta participation pleine d'esprit et d'humour.

[R&B]

Bonjour

Pour information le GDS a été réalisé pour des développeurs voulant profiter du travail collaboratif et qui avaient étudié les cvs et autres solutions.

Toujours pour info, WinDev gère le code A l'INTERIEUR des fenêtres (ou éléments de projet) à la différence des outils qui sont supportés par ces outils. C'est ce qui à conduit à l'élaboration de la solution intégrée qu'est le GDS. Du coup on y gère toutes les composantes du projet et pas uniquement le code.

En conséquence : le travail collaboratif avec gestion automatique des échange passe par la solution propriétaire qu'est le GDS.

Sinon, il peut être effectué par une gestion des éléments de projet. C'est ce que je viens d'abandonner pour un usage du GDS avec beaucoup de bonheur pour peu qu'on essaye de mener la chose comme il se doit. Je l'utilise tant en poste connecté qu'en poste déconnecté.
En clair, sous WD17, le GDS est déjà mûr et propose des contrôles puissants (politique de réintégration etc...).


Enfin, sur les responsables et leurs expériences, il y a matière à dire mais une seul réponse : si votre projet à évolué en terme de fiabilité (ce que je vous souhaite), il est à parier que WinDev en a fait de même... il suffit peut être d'évaluer sans a priori ce qui existe aujourd'hui et fort de cette expérience justement. (oui ça sent le vécu !)

[michel.souris]

Merci pour cette réponse tout à fait pertinente...

[Kyroon]

Bonjour Michel.Souris,

Je me trouve un peu dans le même cas que toi, projet racheté pour compléter notre gamme, et on fait avec ce qu'on a eu. Et on a un peu (voir beaucoup) le même état d'esprit que ta responsable, aucune confiance et les surprises que l'on a eu depuis que l'on gère ce projet nous donne raison.

En ce qui concerne le GDS, autant on a trouvé des solutions alternatives aux 'automatismes' ou au 'tout pret' de PCSoft, autant pour le GDS, on a rien d'autre

Je te fais un petit retour d'expérience du GDS qui dans l'ensemble fonctionne bien :
- Quand tu modifie un objet de ton projet et que tu ne l'as pas pris, il te propose de le prendre [Bien], sauf quand tu modifie le SQL d'un objet requête, là il te laisse faire les modifications, et quand tu cherche à enregistrer, tu ne peux pas car tu n'as pas l'objet. Donc fermeture de l'objet sans enregistrer, et ensuite tu peux le prendre pour refaire ta modification (tu ne peux pas le prendre sans fermer l'objet de l'éditeur auparavant)
- Quand tu renomme un objet dans ton projet, il y a des moments (j'ai pas trop cherché la raison) où l'on perd la synchro entre le GDS et ta solution locale. C'est à dire qu'en locale, ton objet a le nouveau nom et dans le GDS l'ancien, mais là où ça coince c'est que le GDS ne voit rien, il ne te propose pas de récupérer les anciens objets, ni d'intégrer les nouveaux donc à toi de le faire à la main et d'y penser au moment où tu renomme.
- Il y a 2 modes de fonctionnement du GDS, automatique ou Maître/Invité. Chez nous il est en Maître/Invité, ce qui implique que le Maître a pris le projet et que lorsque l'on travail a plusieurs, ce qui nous arrive de temps en temps, les objets ajoutés par les invités ne sont pas intégrés au projet ce qui pose des problèmes quand quelqu'un d'autre récupère l'ensemble du projet et compile. A voir comment ça fonctionne en automatique.
- Aujourd'hui notre mode de fonctionnement fait que lorsque l'on sort une nouvelle version majeure, on créé une nouvelle branche dans le GDS pour conserver le code de cette version et on continue à développer la future version dans la branche principale. Dans la branche de la version en production, on est amené à développer les patchs puis à les reporter ensuite dans la branche principale (classique). Sauf que le GDS fait l'impasse sur certaines modifs comme les requêtes internes par exemple. Donc l'outil de comparaison/merge est a éviter selon moi, on ne peut pas lui faire confiance.
- Les étiquettes du codes ne servent à rien dans le GDS sauf à titre d'information. Je me rappel d'avoir eu une fois un patch a faire, puis au final, on ne le sort pas, hé bien impossible de faire un retour au tag précédent à moins de vérifier les objets 1 par 1, pratique . Donc aujourd'hui je ne rend pas les objets tant que le patch n'est pas sorti.

Donc au final, je dirais que si je pouvais m'en passer je le ferais, mais ça n'est pas possible, donc je m'adapte. Il y a peut être des choses à changer mais je n'ai pas trop le temps de chercher à optimiser.
Si d'autres choses me reviennent, je les ajouterais.

(Je précise que je ne cherche pas à lancer un débats mais juste à faire part des problèmes rencontrés)
Bonne continuation.
[WD16] [GDS15]

[hpascal]

Bonjour

Kyroon, tu as raison il y a quelques soucis avec le GDS mais tu parles du GDS version Windev 15, soit d'une version datant de 3 ans.
Je peux supposer que l'éditeur a apporté des correctifs depuis
De mon coté je rencontre beaucoup moins de problèmes qu'avant, mais il en reste toujours !

Le principal problème pour moi c'est le fait qu'on puisse parfois éditer un objet qu'on n'a pas extrait, tout simplement parce que l'objet local n'est plus en "lecture seule"
Il faudrait que le test ne se base pas que sur l'attribut du fichier, vu que celui ci peut changer pour des raisons x ou y

Ensuite le renommage d'élément pose encore parfois des problèmes mais c'est plus rare de mon coté.

En fait j'évite de faire plusieurs choses en même temps, pour renommer un élément, je l'extrais, je le renomme, je le réintègre, je ferme tout, je ré-ouvre et je vérifie.

J'utilise une base GDS en mode HF Classic car je me déplace souvent avec, et pour éviter les problème il faut faire des repair préventifs réguliers
Je sauvegarde aussi tous les jours la base et mes répertoires locaux, certes ça prend du temps mais ça m'a évité des problèmes, même si, je le répète, il y a moins maintenant

Pour conclure, pour moi windev est un très bon produit, mais je dirais que les outils qui gravitent autour (dont le GDS) ne sont jamais complètement finalisés et ça c'est vraiment pénible !

[michel.souris]

Merci beaucoup Kyroon pour cette réponse circonstanciée ! c'est exactement ce que j'attendais !

[Kyroon]

De rien

tu as raison il y a quelques soucis avec le GDS mais tu parles du GDS version Windev 15, soit d'une version datant de 3 ans.

Effectivement, mais je ne suis pas décisionnaire sur ce point. Le passage à Windev 16 a été fait pour palier un problème hors sujet, et le passage du GDS en 16 n'était pas une nécessité.

Il faudrait que le test ne se base pas que sur l'attribut du fichier, vu que celui ci peut changer pour des raisons x ou y

C'est également ce que j'avais constaté, mais le problème reste entier avec les requêtes. On peut modifier le SQL d'une requête alors que le fichier WDR correspondant est en lecture seule. Ne travaillant qu'en SQL, je me fais avoir régulièrement avec ça, et c'est pénible. Donc soit ce n'est pas le seul élément influençant le test, soit Windev refait la 'conversion' Editeur/SQL à chaque fois. Je penche pour le second cas car quand on sauvegarde un code SQL d'une requête, ça ne sauvegarde pas du côté 'Editeur' alors que l'inverse oui.
(Si à l'occasion quelqu'un peut faire le test de modification d'un code SQL sans avoir pris pour voir si ça a évoluer )

Pour le reste, comme je l'ai dit, je m'adapte. Connaissant les problèmes, j'y fait très attention (les renommages par exemple) mais le tout c'est de les découvrir

On est en HF C/S pour le GDS, et de ce côté là je n'ai jamais eu de soucis. Je n'ai fait faire qu'une seule fois une réparation mais c'était suite à un problème serveur. Pour les sauvegardes, également journalières du répertoire des fichiers côté serveur et de mon répertoire Projet sur mon poste, fait en automatique la nuit par contre

Pour finir, 'aucune confiance' n'est pas forcément péjoratif, ça oblige à faire attention à ce que l'on fait et d'être rigoureux, ce qui pour moi n'est pas forcément une mauvaise chose.

Pour conclure, pour moi Windev est un très bon produit, mais je dirais que les outils qui gravitent autour (dont le GDS) ne sont jamais complètement finalisés et ça c'est vraiment pénible !

Héhé, ça me fait penser à ce que je répond au personne qui me demande ce que je pense de Windev/PCSoft : "Ils ont de très bonne idée, mais ne les finissent jamais" et je trouve ça dommage.

Bonne continuation.

[michel.souris]

Salut zot tout,

Kyroon (ou un autre) si tu passes par là j'aimerais savoir comment vous gérer le partage des fichiers externe de l'appli (genre les ini, log...) qui sont "habituellement" dans le rép. EXE de l'appli dans un contexte monodév.

Bisous

[R&B]

Salut Michel.

Déjà tu mélanges les sources et les données, c'est mal parti.

plus sérieusement, il y a bien un solution car le GDS permet de gérer aussi les documents partagés... hors projet.
Ainsi tu vas dans l'administration du GDS et là tu peut ajouter un dossier et y coller les partages hors projet.
Inconvénient majeur : il te faut WinDev pour assurer les réservation / libération (GDSAdmin.exe). Et donc il est à proscrire d'ouvrir directement le document avec l'application associée.
Avantage : le GDS enregistre les différences binaires des fichiers, on se moque donc du contenu.

Dans ton cas, je t'invite quand même à simplement ajouter les fichiers communs comme éléments du projet (c'est possible aussi) afin qu'il entrent dans le GDS de manière classique (à savoir dans la gestion des sources de ton projet).

Bref, d'un coté ou de l'autre tu doit être en mesure d'y arriver.

[michel.souris]

Yes merci,

C'est que j'ai finalement fait !

[Ry_Yo]

...
- Les étiquettes du codes ne servent à rien dans le GDS sauf à titre d'information. Je me rappel d'avoir eu une fois un patch a faire, puis au final, on ne le sort pas, hé bien impossible de faire un retour au tag précédent à moins de vérifier les objets 1 par 1, pratique . Donc aujourd'hui je ne rend pas les objets tant que le patch n'est pas sorti.
...

Bonjour,

PCSOFT a imaginé les étiquettes pour la génération de l'EXE, pas pour une utilisation manuelle, même si c'est possible (enfin du moins c'est comme cela que je l'ai compris).

Imaginez une version 1.0 de l'appli que je déploie sur mon parc. je la tag lors de la génération de l'EXE.

je continue le dév.. et pour une raison X ou Y, il faut que je revienne à la version 1.

Pour cela j'ouvre le projet :
- GDS / Gestion du projet / Historique du projet

là j'ai une fenêtre qui m'indique quel version est tagué (grâce à la petite icône juste devant le libellé) et j'ai la possibilité de créer une branche à partir de là.
Conséquence, tous les éléments ayant le même tag sera reporté dans la branche.

Donc j'aurais une branche correspondant à la v1.0 et je pourrais merger de manière manuelle ou automatique le dev. succeptible d'apparâitre dans cette branche.

Je vous l'accorde que finalement c'est la branche qui deviendra le dev. principal... et le dev principal qui finalement ne sera plus maintenu....

c'est assez déroutant mais viable une fois qu'on a compris PCSOFT

[curunir]

Bonjour, désolé pour le remontage de sujet mais celui-ci m'intéresse.

Dans l'optique de la quasi obligation d'utiliser le GDS pour gérer les sources PCSOFT,

- quand vous faites une branche, avez vous dans cette branche l'historique des modifications avant la branche ?

- y a t-il un moyen de faire revenir le projet dans sa globalité à une "révision" précédente ? (je ne parle pas ici de passer sur une branche correspondant à une version précédente)

[R&B]

quand vous faites une branche, avez vous dans cette branche l'historique des modifications avant la branche ?

oui, mais attention, vu qu'il existe la possibilité de purger l'historique pour gagner en taille/vitesse, cette purge serait alors contre votre nécessité.
NB : avec HFSQL (19) et ses performances accrues, cela repousse sensiblement les problème.

y a t-il un moyen de faire revenir le projet dans sa globalité à une "révision" précédente ? (je ne parle pas ici de passer sur une branche correspondant à une version précédente)

C'est le principe de l'usage des étiquettes. générez des étiquettes quand vous créez la branche et hop, vous pourrez revenir.

Evidement, pour avoir une fois rencontré un problème inattendu mais corrigé, je vous invite a bien tester personnellement chacun des scénarios que vous avez en tête.