Discussion :

[Worldofdada]

Bonjour,

Je suis actuellement en train de faire une application Windows en C#, je travaille sous Visual Studio avec VSS.
Je dois cependant cr�er N applications � partir de celle ci.

En effet, il y aura des sp�cificit�s pour chaque application et donc un tronc commun (genre des r�gles fonctionnelles qui changent, des boutons en plus ou en moins, un design diff�rent sur certains modules, ...).

J'aurais souhait� avoir vos conseils sur la question suivante :
Comment structurer mon application afin de pouvoir g�rer toutes les diff�rentes versions sans perdre mes sp�cificit�s et sans interferer non plus avec une autre application ?

Sachant qu'une application n'est jamais fig�e et donc que le tronc commun bougera forcemment.
je ne connais pas pour le moment quel sera le tronc commun : il va bouger petit � petit.

Merci
Worldofdada

[SaumonAgile]

Pour ce genre de probl�me, on est pass� � SVN plutot que VSS. On a une branche de d�veloppement 'trunk', ensuite quand on sort une version majeure, on cr�e une branche pour la version majeure, et on merge les modifications du trunk, au fur et � mesure dans les autres branches. A chaque version que l'on diffuse on cr�e un tag des sources compil�es et on archive ce tag dans un r�pertoire 'tag' sp�cifique.
Voici la structure de notre arborescence :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| projet
|   |
|   |- trunk // Sources de développement
|   |- branches
|   |   |- 1.0
|   |   |- 1.5
|   |   |- 2.0
|   |   |- 3.0
|   |- tags
|   |   |- 1.0
|   |   |- 1.1
|   |   |- 1.2
|   |   |- 1.3
|   |   |- 1.5
|   |   |- 1.6
etc

[Worldofdada]

Merci pour cette r�ponse mais je ne comprends pas tr�s bien.

Ma probl�matique n'est pas d'archiver correctement chaque "version" de l'application (1.1, 1.2, ...) mais chaque "�dition" pour chaque version.

J'imagine notre sch�ma VSS de la mani�re suivante mais je ne vois pas comment faire pour optimiser la chose dans VSS et dans les d�veloppements.

Head
|-v1.1
| |-TOTO
| |-TATA
|-v1.2
| |-TOTO
| |-TATA
|-v1.3
| |-TOTO
| |-TATA
| |-TUTU
.....................

Mon soucis est que 90% des fonctionnalit�s, fenetres ... vont etre communes.
Seuls quelques points vont bouger mais je ne sais pas encore lesquels.

Si je fais une modification commune � toutes les �ditions entre la 1.2 et la 1.3, je ne vois pas comment faire pour ne pas r�p�ter la modification 3 fois (pour les 3 �ditions) et ainsi de ne pas multiplier le risque d'anomalie par 3.

[SaumonAgile]

On fusionne les modifications du trunk dans les branches concern�es, donc oui �a fait un peu de travail mais avec les scripts qui vont bien, �a marche.
Si tu cr�es des sources diff�rentes pour chaque version, tu n'as pas trop le choix, il faut reporter les modifs dans chaque version � chaque fois.

[Worldofdada]

ok, je vais essayer d'analyser une solution de plug in avec des dll pour chaque module qui peut avoir des sp�cificit�s.

Sinon, cot� base de donn�es, tu as une solution (il y a des nouveaux champs, nouvelles proc�dures stock�es, ...) ?

[SaumonAgile]

Versionner le sch�ma de la base, c'est la solution que l'on a retenue.