El Titi a écrit 3953 commentaires

Bonjour

merci pour vos réponses.
Il semblerait en effet que le problème d'accès soit lié à mon poste de travail.
ce qui ne semble pas être le cas pour le tutoriel Papyrus en revanche
http://www.eclipse.org/modeling/mdt/papyrus/usersCorner/user(...)
et le guide reste encore à compléter
http://wiki.eclipse.org/Papyrus_User_Guide#Collaborative_Wor(...)

Si j'essaie de comprendre, un certain nombre de composants du projet Topcased ont migré vers Papyrus et Topcased représente aujourd'hui un sur-ensemble de ce dernier.

Concernant l'aspect collaboratif, si je m'en tiens aux autres commentaires, on peut en déduire que Papyrus UML ne s'intègre pas avec CDO aujourd'hui et que donc il faut s'appuyer sur l'outil de contrôle de version et le découpage en sous-modèle.
(Sachant que la gestion des merge avec SVN est relativement bancale et que les DVCS ne supportent pas le verrouillage exclusif des fichiers)

Cette fonctionnalité supporte-t'elle une vue logique du modèle qui permet d'assurer l'intégrité du modèle en cas d'édition concurrente sur plusieurs fichiers associés à un même modèle ?

Papyrus propose t'il une interface de fusion de modèle UML équivalente à RSA (merge 3 contributeurs et combined merge)

Est-'il prévu d'intégrer les diagrammes dans le même fichier que celui du modèle car le fait qu'il soit séparé par défaut est assez pénalisant ?

Si toutes ces conditions ne sont pas réunies ne sommes nous pas encore à assez loin d'une utilisation industrielle pour modéliser en équipe ?

Pourrais tu préciser.

CDO se basant sur une db, ne s'agirait t'il pas plutôt d'un cache de donnée et donc d'une conception centralisée ala SVN ?
Mais bon en contexte d'entreprise, ceci ne me gêne pas plus que ça.

Le branching supporte t'il la mémoire de merge, car devoir remerger complètement 2 modèles lorsqu'on a arbitré les décisions serait loin d'être suffisant (cas d'utilisation: réconcilier itérativement 2 versions de modèle entre 2 branches, l'une provenant d'une transfo M2M et l'autre ayant été raffinée par une équipe).

Supporte t'il également le verrouillage exclusif sur des portions de modèles ?

Est-il compatible avec tous les modeleurs EMF based ?

Merci pour vos précisions.

Ici nous utilisons RSA + gestionnaire de version et l'unité de contrôle peut descendre au niveau de l'élément. L'intégrité des modèle après fragmentation est assurée par le Logical Model Provider, donc ce n'est pas vraiment un problème.

L'IHM pour le merge 3 contributeurs et pour la combinaison de modèle sont assez puissants et utilisables pour supporter une véritable approche model driven. Ils autorisent une approche itérative et incrémentale, y compris au niveau une chaine de transformation de modèles.

Je vais me reposer la question de CDO. D'après ton expérience Papyrus ne semble pas encore prêt. Qu'en est-il de Topcased ?
Avec quel modeleur avez-vous couplé CDO ?
Je sais que Topcased est plus abouti pour une utilisation avancée mais je lui reproche son IHM pas toujours très intuitive pour des non techniciens. Ceci était en revanche le point fort de Papyrus avant son intégration au projet Eclipse.
N'envisagez vous pas une collaboration entre les 2 équipes voire une fusion à terme ?

Merci en tous ca pour vos précisions ainsi qu'à Cédric.

Il me semblait que Jazz s'appuyait sur des CVS dont un embarqué (Jazz source Control). CDO c'est plutôt orienté base de données non ? Quid des worfklows parallèles et des merges.

Ca devient une obsession là:
http://linuxfr.org/comments/1167517,1.html

Fais pas ta jalouse

http://linuxfr.org/~farvardin/30077.html

Au fait, le "changement de technologie" correspond-t'il au passage sous uml2/emf d'eclipse plutôt qu'une surcouche adaptée de gmf ?

Je ne voudrais pas paraître désobligeant, mais j'aurais apprécié quelquechose de plus étoffé pour présenter le projet.

Je ne vois aucune release notes qui nous présente les nouveautés depuis que le projet a intégré Eclipse. Et même en cherchant sur le site je n'ai pas trouvé.
La présentation ne fonctionne pas
http://www.slideshare.net/rfaudou/papyrus-eclipse-con-2010-v(...)

J'aurais également apprécié quelque nouvelles sur le statut du projet (Il était question d'un merge avec Topcased un temps, je crois)
Un sybillyn "Papyrus représente un projet très actif." me laisse un peu sur ma faim.

Qu'en est-il de la modélisation en équipe (fragmentation, merge de modèles, ...) qui me parait essentielle pour pratiquer "l'ingénierie des modèles" autrement que seul dans son labo ?

Bref, ca plus les références aux outils de transfo, ca me laisse un léger goût de publi-reportage dans la bouche.

Oui, vaut mieux tirer avec la Rigaux qu'avec la grosse Bertha.

Franchement, y a des claques qui se perdent.


Je ne te le fais pas dire.
Le gars, il publie un hack dans un journal pour en faire profiter tout le monde alors qu'il a fait ca pour lui, il utilise ce qu'il connaît, qu'il affectionne et qui va à l'essentiel.
Il donne un peu de son temps pour produire un truc qui marche.
On l'encourage à poster une news parce que ca serait sympa.

Et là évidemment y'a des bozos qui débarquent pour le tâcler en lui disant qu'il faut qu'il refasse tout ça en assembleur parce que voilà Python c'est naze. Et pis faudrait qu'il fasse ca à plein temps et gratos en plus (libre pardon, mais je suis sûr que tu vas te précipiter sur Paypal une fois qu'il a aura tout réécrit) parce qu'un hack comme ca c'est une injure aux utilisateurs rois de DLFP.

Alors oui y'a des claques qui se perdent
Et là, j'ai envie de dire t'as qu'à sortir tes petits doigts boudinés et le faire toi-même le fork en C, le code est en GPL.

Eviv Bulgroz !

J'en ai les mains toutes mouettes.

Ouais, la GPL c'est nul. Vive la LGPL !

Bonne question, je me demandais comment il était si simple de forker un projet lorsqu'on ne détient pas le copyright.

Avec Linux le passage GPLv2 vers v3 est impossible car il faut que tous les auteurs soient d'accord.
Si le projet passe en GPLv3, on retombe dans le même pb, si on refuse une cession de copyright à une unique entité. Tout passage à une autre licence ou version devient compliqué.

Est-ce qu'avec une LGPL on fait ce qu'on veut ? (A priori c'est l'intérêt de cette licence)

Un spécialiste es licences pour corriger ?

Je crois que l'idée est de faire des petits utilitaires simples et de les proposer à qui veut bien.

Parcher rsync ca nécessite de se mettre au C, de s'impliquer dans un projet qui n'a pas la même vocation (par ex le renommage de fichiers pour éviter l'écrasement n'est pas trivial en utilisant un outil de synchro)
Sinon, faire un backend à un programme qui ne propose pas d'API n'est pas forcément du goût de tout le monde (pas du mien en tout cas)
http://www.mail-archive.com/rsync@lists.samba.org/msg18288.h(...)

Est-ce que tu as moyen de détecter simplement que 2 partitions ne sont pas sur le même disque ?
Parce que sinon ton optimisation ne marche pas toujours.

Ultracopier ayant eu son heure de gloire sur DLFP:
http://linuxfr.org//2010/01/24/26384.html

ca parait être une bonne idée.

Et pour vous mâcher le travail

j'ai «profité» de la perte de ma boîte de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je
...
Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
Et je finis avec un petit lien vers mes autres projets en cours:
-lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et ...

Un journal soigné et du bon boulot en tout cas.

Ca serait pas mal de créer une catégorie "coup de coeur" pour les petits projets qui se lancent.

https://bugzilla.redhat.com">notre système de suivi d'anomalies.

avec comme url
https://linuxfr.org/submit/%3Ca%20href=



et mêmes les plus ancienne

même est un adverbe ici
http://francite.net/education/cyberprof/page111.html



les bindings Python développés par Nokia sous licence LGPL. L'environnement GNUStep est également introduit.

Autres temps, autres moeurs.

Dans une autre vie, les lapsus te servaient visiblement d'argumentaire:
http://linuxfr.org/comments/822108.html#822108
http://linuxfr.org/~euroxers/23509.html

En même temps elle est excusable, l'inflation aussi fait gonfler ... les prix.

http://www.agoravox.fr/culture-loisirs/dessin-du-jour/articl(...)

Oui, quand est-ce qu'on pourra utiliser librement les données qui ont été collectées grâce à nos impôts ?

C'est balo, hein ?
Non, mais c'est ballot
http://fr.wiktionary.org/wiki/c%E2%80%99est_ballot

Simplement parce que le branching avec SVN est bloated. Une usine à gaz a été créé pour pallier les défauts d'architecture que j'ai exposé un peu plus loin.
Cette belle idée au départ de pouvoir brancher à plat directement dans l'arborescence couplée avec cette notion de révisions qui simule des "liens symboliques" et qui pointe que sur les fichiers modifiés depuis la dernière révision était séduisante. (branche et tags en O(n)). L'équipe SVN s'était dit qu'ils s'occuperaient des branches plus tard (mémoire de merge, rename tracking, pas de merge cycliques, ... par exemple) et dans les faits c'est tout qui est à revoir. (pour le rename tracking il faut des identifiants d'objet alors qu'on a que des révsions ou un DAG+notion de branche pour être efficace). Leur modèle se complique (mergeinfo qu'il faut supprimer à la main, révisions à indiquer explicitement parce la mémoire de merge est défaillante, option reintegrate pour traiter les branches de patch, ...) Ils sont dans une impasse ... Ca explique pourquoi on trouve ca dans la section advanced.

http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)

Du coup on conseille de bosser dans une branche et on promeut l'intégration continue puisqu'on ne sait traiter que ça.

Désolé, j'ai rien compris à ce que tu voulais expliquer.