Discussion :

[Caradoc]

Bonjour,
J'utilise Bouml depuis peu. Je compte partager mon projet avec plusieurs collègues (pour l'instant 2) via SVN.
J'utilise les plugouts Check-in et Check-out avec les commandes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
svn ci -m "..." %dir/%file
svn up %dir/%file

Ca à l'air de fonctionner, mais je me pose plusieurs questions (auxquelles je n'ai pas trouvé de réponses claire dans la doc) :

1. Quels sont les fichiers qu'il est pertinent de mettre sous SVN ?
2. Faut-il un BOUML_ID différend pour chaque utilisateur, même s'ils travaillent chacun sur une copie du projet ?
3. Apparement, la commande svn est appelée pour chaque fichier, ce qui casse l'atomicité du check-in et qui empêche le check-out de nouveaux fichiers.

[bruno_pages]

Bonjour,

Quels sont les fichiers qu'il est pertinent de mettre sous SVN ?

si le but est de gerer le projet (au sens bouml) en gestion de conf : tout les fichiers du projets, sauf les temporaires

Faut-il un BOUML_ID différend pour chaque utilisateur, même s'ils travaillent chacun sur une copie du projet ?

Bien-sur !

La documentation dit d'utiliser des BOUMl_IDs différents pour chaque personne travaillant sur un même projet, il n'y a pas de conditions supplémentaires infirmant la chose

Le mieux est que chacun est un BOUML_ID personnel indépendamment de tout projet en le fixant donc une fois pour toute

Si vous avez déjà travaillé à plusieurs avec le même BOUML_ID sur le même projet il n'y a plus qu'a jeter les projets sauf une version

D'autre part, si vous travaillez sur des copies la gestion de configuration ne protegera pas les modifications en //, si vous ne voulez pas avoir à merger les fichiers du modèle il faut vous répartir le travail en découpant le modèle et en utilisant project control et project synchro, lire Développer un projet à plusieurs avec Bouml

Apparement, la commande svn est appelée pour chaque fichier, ce qui casse l'atomicité du check-in et qui empêche le check-out de nouveaux fichiers.

je ne comprends pas le problème concernant le check-out

[Caradoc]

Merci pour ta réponse.

si le but est de gerer le projet (au sens bouml) en gestion de conf : tout les fichiers du projets, sauf les temporaires

Ok. En regardant la doc, j'en avais déduis que la liste exhaustives des fichiers temporaires sont:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<user_id>.session
<user_id>.b
<user_id>.d
<user_id>.lock

D'autre part, si vous travaillez sur des copies la gestion de configuration ne protegera pas les modifications en //, si vous ne voulez pas avoir à merger les fichiers du modèle il faut vous répartir le travail en découpant le modèle et en utilisant project control et project synchro, lire Développer un projet à plusieurs avec Bouml

Oui, j'avais regardé la doc de project control et project synchro, un peu vite je l'avoue. Dans un premier, je voulais éviter d'assigner un fichier à une personne, et évaluer ce qu'implique de modifier le projet en parallèle avant de regarder cette solution de plus près.

je ne comprends pas le problème concernant le check-out

Et bien, par exemple, si mon collègue ajoute un nouveau diagramme, lorsque je fais de mon côté Check-out via Bouml, celui-ci va exécuter ma commande svn up pour chaque fichier que lui connait. Il ne peut pas exécuter svn up du nouveau fichier (où alors y'a un truc que je n'ai pas compris).

D'un autre côté je me dis que Bouml non plus ne re-loaderas pas les nouveaux fichiers puisqu'il ne les connais pas tant que le projet n'a pas été "fermé / ouvert"...

Bon, je crois que je vais laisser tomber les Check-in et Check-out et regarder project control et project synchro. Ca devient hors sujet, j'ouvrirais un autre sujet si j'ai encore besoin d'aide

[bruno_pages]

En regardant la doc, j'en avais déduis que la liste exhaustives des fichiers temporaires sont:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<user_id>.session
<user_id>.b
<user_id>.d
<user_id>.lock

il y a aussi les fichiers creer lorsque les corps des operations ou autre sont edités avec un editeur externe

les fichier temporaires sont *_<n>.* où <n> est un nombre (le BOUML_ID de quelqu'un utilisant Bouml)

Dans un premier, je voulais éviter d'assigner un fichier à une personne

en fait le découpage est par package car chaque package à un fichier associé

Et bien, par exemple, si mon collègue ajoute un nouveau diagramme, lorsque je fais de mon côté Check-out via Bouml, celui-ci va exécuter ma commande svn up pour chaque fichier que lui connait. Il ne peut pas exécuter svn up du nouveau fichier (où alors y'a un truc que je n'ai pas compris).

ok, je ne connais pas SVN

pour la raison que tu évoques il ne faut pas de faire des svn up à partir de Bouml. De toute facon svn up n'est pas l'équivalent d'un check-in ni un check-out, je ne comprends donc pas pourquoi tu as fait la liaison

[Caradoc]

Je fais un point.
J'ai opté pour la solution "SVN + ProjectControl".
Si j'ai bien compris, un protocole d'utilisation serait de :

1. assigner un BOUML_ID par utilisateur
2. lister les fichiers temporaires dans svn:ignore
3. assigner chaque package à un utilisateur dès leur création (du moins avant de l'ajouter dans svn), afin d'évite les merges intempestif.
4. mettre en protect chaque package que l'on considère comme définitif (ce qui peut évidement changer). En fait, ça ne me semble pas obligatoire, mais ça fait joli d'ajouter du rouge dans l'arbre à package
5. s'assurer que l'on est à jour avant de changer le propriétaire d'un package. Là je suis encore un peu flou. Je suppose que dans l'esprit, ProjectControl n'est utilisé que par une seule personne ?

[Caradoc]

J'ai loupé ce point :

[...] De toute facon svn up n'est pas l'équivalent d'un check-in ni un check-out, je ne comprends donc pas pourquoi tu as fait la liaison

Du coup je ne comprends plus grand chose non plus.
Pour moi, un check-out dans svn (et cvs) permet de récupérer un module complet tel qu'il est dans le repository. Normalement cela n'est fait qu'une fois par utilisateur. Ensuite, il faut faire un svn up (update) pour récupérer les éventuelles modifications descendues par d'autres utilsateurs.
J'ai effectivement interprété "Check-out" en "update". C'est apparement une erreur, mais du coup je ne comprends plus l'objet de ce plugout

[bruno_pages]

J'ai opté pour la solution "SVN + ProjectControl".

dans le cas ou il y a plusieurs copies du projet il faut ajouter project synchro qui est le synchronisateur des modifications faites en parallèle

lister les fichiers temporaires dans svn:ignore

cela risque d'être difficile à cause des fichiers liés à l'édition des opérations, sauf bien-sûr s'il est possible d'utiliser des filtres

la meilleure option pour ne pas avoir de problème est de rentrer les fichiers en gestion de conf une fois sorti de Bouml car il n'y a alors pas de fichiers temporaires

assigner chaque package à un utilisateur dès leur création (du moins avant de l'ajouter dans svn), afin d'évite les merges intempestif.

oui ou même une branche de l'arbre des packages, ce qui correspond à une sorte de 'sous système' à priori

mettre en protect chaque package que l'on considère comme définitif (ce qui peut évidement changer). En fait, ça ne me semble pas obligatoire, mais ça fait joli d'ajouter du rouge dans l'arbre à package

et cela 'bétonne' l'utilisation

s'assurer que l'on est à jour avant de changer le propriétaire d'un package.

il est impératif d'utiliser project sychro avant de changer le propriétaire d'un package (par contre c'est inutile lorsqu'un package protégé est assigné à quelqu'un)

Là je suis encore un peu flou. Je suppose que dans l'esprit, ProjectControl n'est utilisé que par une seule personne ?

pourquoi pas (un intégrateur donc)

mais ce qui compte c'est que project control et project synchro ne soient pas utilisés en // (je vérifie qu'il n'y a pas de .lock mais cela ne marche évidemment pas s'il sont utilisés en // et sur des copies séparées)

project control et synchro doivent d'appliquer à l'ensemble des copies du projet, on est ainsi sure de ne pas faire de bétises et d'avoir deux personnes pouvant modifier simultanément un même package.

Si vous le pouvez utilisez un disque partagé et non plusieurs copies de projet, cela vous évitera d'utiliser project synchro

[bruno_pages]

...suite réponse précédante

Pour moi, un check-out dans svn (et cvs) permet de récupérer un module complet tel qu'il est dans le repository.

Non, ce sont des concepts clear-case / droit de modification

Au départ personne ne peut modifier un fichier. Check-out donne le droit de modification à un utilisateur. Check-in met à jour le repository pour mémoriser les modifications et retire le droit de modification (retour à la case départ)

CVS et SVN n'ont pas de 'vrais' check-in/out

[Caradoc]

Après discussion avec des collègues et recherche dans la doc de Subversion (voir ici), je pense mieux comprendre l'usage des plugouts Check-in et Check-out.

En résumé, pour gérer des fichiers "non-mergeables" (par exemple une image), Subversion propose d'utiliser la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
svn lock <file>
svn unlock <file>

qui empêche tout autre utilisateur de descendre une modification dans la base svn.
Cela doit correspondre au Check-out de bouml ?

En plus de cette commande, on peut ajouter la propriété "svn:needs-lock" à chaque fichier "non-mergeable", ce qui rend le fichier read-only (au niveau file system). De cette façon, un utilisateur est obligé de faire un lock sur ce fichier pour pouvoir le modifier (ce qui est bien sûr impossible si un autre utilisateur a déjà locké ce fichier).

Comme Bouml utilise intelligement la propriété readonly des fichiers, il me semble que du coup je n'ai pas besoin de ProjectControl.

En résumé :

1. Etat initial du projet : tout les fichiers non temporaires sous SVN, avec la propriété svn:needs-lock + une extraction du projet chez chaque utilisateur où tout les fichiers sont readonly.
2. Arthur a ouvert son projet dans Bouml : il ne peut rien modifier
3. Arthur veut modifier le package Toto. Il clique-droit sur le package et choisit Tools / Check-out et utilise la commande svn lock %dir/%file (en cochant check-out the sub-packages)
4. Marvin veut modifier le package Toto : il ne peut pas car les fichiers correspondant sont lockés dans svn
5. Arthur a terminer sa modification : il utilise le plugout Check-in avec la commande svn commit -m "..." %dir/%file
6. Alternative : si Arthur ne fait finalement pas de modification, il faut exécuter svn unlock %dir/%file
7. Marvin veut à nouveau modifier le package Toto : il ne peut toujours pas car ses fichiers correspondant son out-of-date : il doit faire un svn update.
8. Marvin peut à son tour modifier le package Toto

Ca à l'air bien, non ?

[bruno_pages]

Ca à l'air bien, non ?

oui

il va quand même falloir insérer des svn update 'un peu partout', par exemple avant de faire les svn locks. Sans doute se méfier des updates simultanés avec des commits, mais cela c'est du 'classique'

je suppose que commit fait un unlock ?

je suppose que update est global : il faut tout mettre à jour sous peine d'introduire des incohérences

En tout cas ainsi tu n'as effectivement plus besoin de ProjectControl, car le but de celui-ci est justement de palier au fait que l'on ne puisse pas donner le droit d'écriture à 0 ou 1 seule personne et pas aux autres.

Bonnes modélisations

[Caradoc]

il va quand même falloir insérer des svn update 'un peu partout', par exemple avant de faire les svn locks. Sans doute se méfier des updates simultanés avec des commits, mais cela c'est du 'classique'

Tout à fait.

je suppose que commit fait un unlock ?

Exact, mais seulement s'il y a effectivement une modification. Du coup j'utlise un script (comme décrit dans le sujet Utilisation de CVS dans BOUML) qui s'assure de faire unlock quand même.

je suppose que update est global : il faut tout mettre à jour sous peine d'introduire des incohérences

Oui, je fais toujours des updates globaux.

En tout cas ainsi tu n'as effectivement plus besoin de ProjectControl, car le but de celui-ci est justement de palier au fait que l'on ne puisse pas donner le droit d'écriture à 0 ou 1 seule personne et pas aux autres.

Bonnes modélisations

Merci. Probablement à bientôt pour d'autres questions.