Dans mon équipe (20 personnes), nous sommes en train d'utiliser Subversion, nous faisons  toutes les étapes que t'as défini [update/check in/lock/ commit(automatiquement le check out)] et nous avons pas ce genre des problèmes.

je te conseille de supprimer d'abord la PBL de ton PC puis fait le update 

Ah, je suis désolé toto j'ai pas lu cette phrase.

toto a écrit:

Au départ, on a un repository avec toutes les PBLs et tous les objets PB générés pour ces PBLs.

En fait, j'ai cru que tu travaille seulement avec les PBLs. Au début du projet, j'ai essayé de travailler sous SVN avec les objets des PBLs, mais après on a conclu que la manipulation de ces objets sous SVN assez difficile.

Je voudrais dire par la phrase "supprimer d'abord la PBL de ton PC puis fait le update" parce que quand vous avez toutes les PBLs dans le serveur SVN tu peux la supprimer et de faire une update pour récupérer de subversion la bonne version de la PBL.

merci et bon courage

Dernière modification par mattdamon (16-02-2009 17:45:43)

Buck,

je me doute que ma méthode n'est pas la bonne et nous cause bcp de problèmes.
J'attend avec impatience tes explications détaillées !

Merci d'avance,
Bernard

Alors Bernard, tu as réussi à t'en sortir ?
Un petit retour serait le bienvenu, surtout pour buck qui a passé du temps la-dessus...

Bonjour,

Tout d'abord merci, j'aime bien avoir un retour même s'il est négatif ça permet de se remettre en cause ou de modifier le document de façon adéquate.

Car ce que je craint maintenant, c'est quand 2 développeurs travailleront sur le même objet PB et qu'ils feront un check-in, c'est que la gestion des conflits ne se fasse pas et que le dernier à faire le check-in écrase les modifs du premier...
==> Mais nous avons peu de cas où 2 personnes travaillent sur le même objet (13000 objets PB). Donc, comme c'est moi qui distribue le travail, il faudra que je sois vigilant à ce que les tâches de chacun ne se marchent pas dessus.

L'intérêt d'un gestionnaire est justement de s'affranchir de cette problématique. J'ai ajouté un chapitre 6 au tutoriel : Gestion de la concurrence d'accès.

Il faut travailler en mode "reserved checkout", ainsi un verrou est posé sur le fichier et interdit la modification par un autre utilisateur.

Le poste utilisateur est informé de la modification de l'objet par un autre utilisateur par le changement de l'icone de statut de l'objet (croix rouge) et interdit l'édition. De même, l'utilisateur est informé qu'il ne dispose pas de la dernière version de l'objet par un autre icône de statut (fléche circulaire).

Sinon, je me suis rendu compte qu'un des problèmes majeurs que nous avons est vraisemblablement lié aux attributs RO des librairies (PBL) et des objets PB.
Sur chacun des postes, jusqu'à présent, toutes les PBL étaient en RO et on avait des problèmes lors de la récupération des modifs effectuées par les autres développeurs. En ayant positionné toutes les PBL en RW, on n'a plus de problèmes... pour le moment.

Par expérience, Powerbuilder n'aime pas trop et ça rend l'environnement particulièrement instable. De plus, on est embêté avec les "regenerate" et "full rebuild".

Bonjour,

La philosophie est très simple. Il faut simplement que tu perdes la notion de PBL sous source contrôle tu travailles à l'objet.

Lorsque, tu veux modifier un objet :

- Tu fais un check-in dessus (OK) => tu as alors une petite coche verte devant l'objet indiquant que tu as pris possession de l'objet (sur les autres postes, il s'actualise au bout d'un certain temps avec une petite croix rouge pour indiquer la modification en cours de l'objet par un autre utilisateur (avec concurrence d'accès correctement configurée).

- Lorsque, tu as finis tes modifications, tu fais un check-out : l'objet est exporté au format texte dans ton répertoire puis il est utilisé pour mettre à jour sur le serveur de sources (sur ton poste, le numéro de version de l'objet est incrémenté (=> library), il y a à nouveau un point vert. sur les autres postes, ils doivent au bout d'un moment s'actualiser avec une petite flèche circulaire devant l'objet pour indiquer qu'il n'ont pas la dernière version (forcer éventuellement avec "refresh status"), ils font alors un "Get Latest Version" pour actualiser leur poste).

Dans PB, faut-il faire un Get Latest Version sur la PBL sur laquelle on souhaite travailler, avant d'apporter des modifs, ou bien il suffit de faire des check-out et lors du check-in, si conflit il y a, il sera signalé ???

Le "Get Latest Version" est seulement nécessaire lorsque tu ne possèdes pas la dernière version de l'objet sur ton poste. Ceci est indiqué par une petite flèche verte circulaire devant l'objet.

Donc, pour éviter ça, après avoir fait mon check-in de l'objet modifié, je fait un COMMIT manuel de ma PBL pour être sûr que la dernière version se trouve bien sur le serveur de sources...

Tu ne fais pas de "commit" manuel de la pbl, car il n'a pas lieu d'avoir la PBL sur le serveur de sources.
=> Oubli la notion de PBL, il n'y a en aucun cas de PBL sur le serveur de sources. Il y a seulement un fichier PBG (et les objets textes de ta PBL) qui porte le nom de la PBL contenant le descriptif des objets de la PBL.
Le fichier PBG est automatiquement mis à jour par Push-OK lorsque tu ajoutes un nouvelle objet de ta PBL sous source contrôle.

Si tu dois configurer un nouveau poste avec le projet consulte le chapitre 7 du tutorial => Récupération d’une copie de travail sur un nouveau poste. ORCA te permet de ré extraire automatiquement tous les objets dans le répertoire local de ton poste et génère automatiquement les PBL à partir des fichiers descriptifs PBG et réimporte les objets dans les PBL.

Est-ce que quelqu'un pourrait m'indiquer ce qu'il faut "garder" en local (j'ai tous les objets au format texte, les .pbl et les .prp), ce qu'il faut gérer en conf sur le serveur de sources (je pense les même objets qu'en local)

Les objets contenus dans ta PBL exportés dans ton répertoire servent uniquement à Push-OK pour actualiser la version de l'objet sur le serveur de sources. Tu peux activer dans les propriétés du workspace (onglet source control) l'option : "Delete Powerbuilder-generated Object files". Ainsi, les objets seront automatiquement supprimés de ton répertoire après la mise à jour sur le serveur de sources.

Encore une chose : en local, j'ai donc mes PBLs. Dans PB, quand je fais un check-out d'un objet, il me jette. Je suis obligé d'enlever la propriété Read-Only de la PBL avec l'explorateur et là je peux faire mon check-out... Qu'en pensez-vous ?

Les PBL sur ton poste local ne doivent pas être en lecture seule.

Et un dernier point : Mattdamon a dit précédemment que je n'avais pas besoin des .pbl sur mon poste. Mais dans ce cas, comment PB va travaillent et quand je devrai générer un nouvel exe, comment vais-je procéder ?

Tu as raisons, les pbl sont nécessaires au fonctionnement de ton application Powerbuilder, elles doivent être présente sur ton poste (mais pas sur le serveur de sources).

Salut à tous,

Merci pour le tuto Buck, en revanche j'ai un souci avec la partie 7 du tuto lorsque je lance mon script ORCA ça plante :s
Impossible de reconstruire les Pbl du coup il me dit :

Calling cm_rebuild_application(CM_REBUILD_FULL).
Library: c:\test\sourcespb\monapplication\src\monappli.pbl
     Object: monappli
         Global Variables
             (0002): Error       C0001: Illegal data type: nvuo_monobjet
Errors encountered during import/compile.  Check SMS log.

l'objet en question est un objet non visuel déclaré en tant que global de l'application et qui ne pose aucun souci lorsque l'on compile les pbl avant l'utilisation du source contrôle

Si quelqu'un a une idée je suis preneur

Merci :-)

EDIT : Petite précision, l'objet qui est référencé par le .sra n'est pas dans la même pbl, ni dans le même répertoire car il s'agit d'un ancêtre commun à plusieurs applications.

Dernière modification par Praet (15-10-2009 09:06:20)

Hé bien en fait il n'est pas dans le même pbg mais dans un autre car à l'origine il n'était pas dans la même pbl.
D'ailleurs autre question les pbl sont elles toujours limitées en nombre d'objets ?

Merci

Pour la taille des PBL, il est effectivement recommandé de ne pas mettre trop d'objets dedans, car ceci est consommateur de mémoire.
De même, il est important de bien structurer dès le départ son application afin de ne pas avoir à charger en mémoire trop de PBDs
volumineuses.

La raison d'un échec d'un "full rebuild" après extraction du dépôt est essentiellement due à deux raisons :

- Les fichiers PBG (dans le dépôt) contenant la liste des objets à intégrer dans chaque PBL est incomplet.
- La target n'est pas à jour et ne contient pas la totalité de la liste des pbl du projet
- Réintégration partielle de plusieurs objets inter-dépendant (dépôt non totalement mis à jour).

Une piste est d'ouvrir la target reconstruite par ORCA et de vérifier la liste des objets dans les PBL par rapport au projet original pour détecter l'éventuel PBG qui n'est pas à jour, la raison de l'échec indiquant en général la piste à suivre (ton global objet ne doit pas être réintégré dans une PBL).

n'oublie pas le [RESOLU]