Nous venons de passer un projet existant en multi-développeurs.

Nous sommes sous WinXp Pro. J'ai déjà rencontré plusieurs formes de plantage système sur le poste où est stocké le projet. Etant en phase de test, je voulais avoir vos avis et expériences sur le développement d'un projet à plusieurs.

Merci

Nous hébergeons les sources notre projet sur un serveur windows 2000 server. C'est juste un répertoire partagé. Nous sommes 4 développeurs sur ce projet.
Nous n'avons pas de plantage du serveur hébergeant les sources néanmoins nous avons les problèmes suivants:

Plantages de windev de temps en temps durant une compilation due à une synchronisation.

Freeze du réseau de temps en temps (genre quand nous sommes 2 à lancer l'application par windev en même temps).

Erreurs de compilations car quelqu'un a fait des modifs dans son code, n'a pas encore réintégré et pourtant on a des erreurs sans les voir dans le débuggeur (mais ça ça vient de la 33t, on avait pas ce pb en 28m).

Pas mal de petites tracasseries mais si quelqu'un avait des idées sur les freezes réseau quand on lance l'appli en même temps, je suis preneur.

Avez-vous transmis ces éléments au support technique et si oui quelle a été la réponse ?

NB : Lors de la synchro du projet, j'ai eu un plantage systématique de l'os. En fait, c'est la collection de procédure globale wdg qui plantait. (Il a trouvé que la version était différente, ce qui est faux). Nous avons du récupérer une sauvegarde et travaillons chacun en local. Nous attendrons une prochaine version stabilisée.

Il y a si peu de personnes utilisant le développement de projet à plusieurs ?

Semblerait que oui, pas beaucoup de monde semble développer en windev à plusieurs.

Avez-vous transmis ces éléments au ST ?

Pas encore, c'est tout récent. Ca s'est démultiplé quand on est passé à 4 dev (y a qques jours).
On doit les appeller dans la semaine.

Merci de me tenir informé du retour ST.

La réponse du service technique :
Tester la version 34i (qui n'a pas encore passé le second niveau de tests). Selon eux, soit cela règle les bugs et c'est tant mieux, soit ça les règle pas et ça change rien. Ils ne parlent pas d'éventuels nouveaux bugs cachés amenés par la 34i dans leur mail...
Mais pour une application qui doit être livrée en septembre chez nos clients, ça nous gêne de passer à une version pas encore complètement validée et qui risquerait de donner des bugs au niveau de l'exécutable (la 33t pose des pbs au niveau de l'environnement de dev mais les fichiers exe générés ne posent pas de pb).

Ce que j'en pense : A mon avis, PCSOFT manque de retour de bugs sur les projets en multi développeurs et c'est la raison de laquelle ils me demandent de tester la 34i. Seulement on est trop proche de la date de livraison du produit pour servir de bêta testeurs. De plus à 4 développeurs sur le projet, si on la teste en condition réelle pendant 4 jours (ce qui est léger) et qu'on est obligés de revenir en arrière, on aura perdu 16 jours de travail homme....

Donc on reste en 33t dont on connait bien les bugs.

Merci de ce retour d'informations. Nous attendrons des retours plus encourageant.

Ah on vient de trouver un nouveau bug sur la 33t et un de 1ère classe....
Si on supprime la rubrique d'un fichier utilisé dans des HlitRecherche, il n'indique pas que la colonne n'existe plus dans la compilation. On ne sait donc qu'il fallait supprimer le HLitRecherche sur cette rubrique que si on recherche à la main dans le code les utilisations de ce fichier ou alors quand le code est exécuté (plantage...)

médaille d'or pour la 33t....
PCSOFT Prévenu, en attente de réponse.

Effectivement... j'espère que tout çà va s'arranger rapidement

J'ai testé cette histoire de HLitRecherche sur des rubriques supprimées sur un projet exemple de Windev et tout fonctionne parfaitement.
Je suppose maintenant que cela vient du multi-développpeurs en lui même ou alors la taille de notre projet qui est trop grosse. Dans les 2 cas, c'est inquiétant.

Bonjour,
Nous sommes une dizaine de développeurs à travailler sur les mêmes sources. Depuis 4 mois nous utilisons CVS pour gérer nos sources.
Par rapport au groupware sur disque réseau qui était utilisé jusqu'alors les gains sont:
-historique précis des modifications avec commentaires directement accessibles,
-économie d'espace disque, car cvs optimise la taille prise par les différentes révisions d'un même fichier,
-meilleure gestion des branches de maintenance et de développement
-possibilité de revenir en arrière aisément,
-temps de compilation réduit.
Nous avions regardé ce qu'il était possible de faire avec WDVersion mais ce produit était trop éloigné des fonctionnalités attendues sur les solutions de versioning.
Un produit nous manque encore, ce serait un comparateur de code W-LANGAGE externe à windev afin de permettre une comparaision de 2 révisions. On peut même réver qu'un jour ce comparateur permette de saisir du code afin de mieux gérer les conflits et une fusion plus simple.
Cordialement,
Franck

Vous arrivez à gérer des sources windev avec un CVS? Je serais bien curieux de savoir comment vous faites pour les gérer. Vous dites que le projet Windev est en mono utilisateur et c'est CVS qui se charge de l'extraction des sources et des droits d'accès?
Pourrais avoir quelques détails?
CVS c'est pas un truc qui tourne que sous linux?

Je suis particulièrement intéressé par la manière dont vous avez résolu ce problème épineux. Merci de me contacter le cas échéant...

En passant à la version 34j, les erreurs de compilation qu'on arrivait pas à visualiser dans le débuggueur sont visibles. Un bug de moins.
PC Soft m'a envoyé un email me prévenant que la version 34j contenait des correctifs sur des bugs que je leur avais remonté. Cette version m'a l'air un peu plus correcte que la 33t.
Je vous tiendrais au courant fur et à mesure des tests.

Je serai fortement intéressé par le retour de vos tests. J'attends toujours une version plus stabilisée pour passer en multidev. La dernière tentative a fusillé la collection globale et le projet ne pouvait plus s'ouvrir. Il a fallu reprendre une svg. Nous avions alors mis en stand by notre passage en multi dev.


Merci

Nous avons basculé en 34j aujourd'hui (dès le matin). Nous allons passer une semaine entière à 4 sur le projet en multi-développeur. je vous dirais ce que cela a donné vendredi. je ne pourrais vous donner qu'une semaine de tests à 4 car je serais absent 2 semaines ensuite.

A noter : On utilise le multi dev en version basique, c'est à dire les extractions/réintégrations et pas plus. On utilise pas le versionning ou autres choses, on fait "simple".

Merci par avance.

Si les extractions fonctionnaient sans soucis, je pense que nous pourrions le mettre en place.