Discussion :

[Clorish]

JE suis en train de monter ma petite libraire perso.
Je vais mettre en place un systeme de versionning pour eviter les erreurs courrantes de compilation de la mauvaise version.

J'ai mis en place dans chaques unitee un numero de version et je souhaite le tester dans chaques unitees l'utilisant.

J'ai pensait faire ce test dans la section Initialisation/Finalmisation de toutes unites l'appelant. Une exception sera levee si le numero requit differe du numero present.

Est une bonne solution ? ou vous me proposez mieux ?

[korntex5]

Je ne suis pas sur de bien comprendre mais les directives de compilations ne te sufisent pas?

[Clorish]

explique toi
Je ne vois pas ce que tu veux dire par "directive de compilation" ...

Mon but est simplement de m'avertir, a la compilation et/ou a l'execution si j'utilise une unitee de version differente que cette requise.

Quand je fait evoluer certaines apis de ces unitees, je les rends incompatible avec des données precedement generees par l'applciation ou bien avec d'autres apis.

Par megarde, etourderie ou autre, l'application fait reference a la nouvelle unitee croyant appeler l'ancienne ... ce qui provoque des bugs a des endroit ou je ne pense pas forcement a chercher ....
Adapter l'application aux nouvelles routines est parfois assez lourd pour etre envisageable.

Donc tout systeme de protection m'avertissant de l'utilisation d'une librairie differente de celle desiree est la bienvenue

[korntex5]

je crois entrevoir ce que tu veux, mais dans ton projet lorsque tu parle de librairie tu parle de composants?
tu veux dire que lorsque tu touche au code de ton composants sans toucher au code de ta unit tu souhaite alors indiquer un numéro de version, pour que lorsque tu compile la unit tu en V1 ou V2 tu sache si tu compile bien avec le composant V1 ou V2 correspondant?

[Clorish]

nopn c'est plus simple que ca.

Je parle d'unite.
Que ce soit des composants (classes) non enregistrées dans l'IDE (ca j'aime pas ... trop galere) ou dans le cas present de simple routines.

Disons que je developper toute une serie d'unitees persos que je regrouppe dans un meme repertoire. Pour le moment je gere le versionning a l'aide de repertoires de nom differents (Version 1.00, Version 1.01, ...)
Je compte d'ailleur garder ce systeme de sauvegarde sur le disque.

Des qu'une unitee a besoin de "gros" changements, incompatibles avec les autres unitees, je cree un nouveau repertoire, copie conforme du precedent et je modifie mes unitees. Une nouvelle version est née.

Par contre, je me traine toute une serie d'unitees de meme nom situes dans des repertoires differents. D'ou la confusion possible si je ne pointe pas vers les bon repertoires. Renomer une unitee en V1, V2, .... serait trop lourd. Changer de version de la librarie, demanderais de changer TOUS les uses ... au lieu d'un simple repertoire.

Bref, je tatonne encore ...
La j'en suis a creer une constante de version que j'inclue a toute unitee, definissant la version de l'unitee.
Du coup un simple test quelque part sur l'ensemble des versions requises et presente permettrait a mon application de "checker" les version et s'assurer que tout est conforme a mes attentes.

PAr contre, je ne sais pas ou et comment effectuer un tel test.
LA section initialisation ?!? Ca demande d'effectuer le teste a l'execution et de se tapper une exception si le test est faux.
Lors de la compilation ? Ca serait le top .. mais je ne vois pas comment ....

[Graffito]

Bonjour,

Des qu'une unitee a besoin de "gros" changements, incompatibles avec les autres unitees, je cree un nouveau repertoire, copie conforme du precedent et je modifie mes unitees. Une nouvelle version est née.

C'est à peu près la solution que nous utilisons avec la variante suivante :
on ne recopie pas les unités inchangées dans le nouveau répertoire et on met ensuite la liste des répertoires successifs dans le bon ordre dans le path de recherche des options du projet.

[Clorish]

Oui c'est vrai.
Mais bon pour eviter des erreurs, je copie les fichiers. C'ets pas pour la place et je n'inclue qu'un seul repertoire.

LEs anciens ne sont encore la que pour preserver une compatibilité avec les anciens programmes.

Mais cela n'empeche pas tout .... alors je me demandais si c'etait possible d'aller plus loin

[Graffito]

L'utilisation des directives de compilation ($DEFINE xxx_nnn, $IFDEF xxx_yyy, ... ) pour tester d'éventuelles erreurs de versions me parait une bonne idée, xxx indiquant le nom du source et nnn le numéro de version.

On peut aussi imaginer que dans chaque unit XXX, il y ait une procedure "bidon" : procedure XXX_nnn ; begin end; et que lorsqu'une unité YYY fait appel à l'unité XXX, il y ait dans la section initialization de YYY l'appel à la procedure XXX_nnn.
Si on se trompe de version, il y aura une erreur de compilation.
Si on change de version de XXX, il suffit de changer le nom de la procedure xxx_nnn en xxx_mmm dans XXX (et remplacer les appels de XXX_nnn par des appels à XXX_mmm là ou on utilise la nouvelle version de XXX).

[Clorish]

Mouais .... effectivement.
Je peux lancer une exception dans initialisaiton si la directive n'ets pas definie.
Si l'unitee chargee est la bonne, la directive ne compile pas l'exeption, sinon elle la compile. L'avantage c'est que je ne me trimpbale pas ce test sur les applcation "correctes".

Bien vu

[korntex5]

oulal je crois que tu es en train de t'embarquer dans un système de versionning dont tu ne verra jamais la fin.
Pourquoi ne pas utiliser des outils fait pour cela?
CVS turtoise par exemple
car comme dans une arborescance tu pourrais avoir ton répertoire avec tes fichier qui serait ton tronc que tu fais évoluer....
puis pour unr raison ou une autre tu décide de créer une branche parallèle au tronc sur laquelle tu développe quelque chose de différent de ton tronc que tu mintient toujours.
tu peux a tout moment revenir à une ancienne version, voir refusioner ton tronc et ta branche ou comparer les évolution entre la version X et Y que ce soit sur un ou tout tes dossiers..

[Clorish]

Oui j'ai deja entendu parle de nombreuses fois de cette methode
Mais faut d'arriver a configurer et utiliser le tout ....

Pour le moment je n'utilise en fait qu'une seulle version. chaques modification fait evoluer ma librairie.
En general, je commence par developper les APIS/Classes en local a mon application, de maniere a ce qu'elles lui soit liée.
Si j'en ai besoin dans uen autre application, je la copie dans la nouvelle application.
Apres plusieurs utilisations, l'api gagne en stabilité et genericite et je l'incorpore dans la librairie standard.

Petite gymnasique qui me permet d'allier au mieux Autonomie des application et reutilisation de code.

Par contre j'au eu a plusieurs reprise eu le besoin de recompiler uen vieille application pour resoudre un bug mineur, mais la librairie avait trop evoluée et me demandais 2 jours de boulot pour l'adapter afin de recompiler une simple erreur d'orthographe ....
Le temps biens sur d'avoir ces 2 jours a consacrer pour mettre a jour proprement mon application.

Je garde donc en archive les anciennes versions pour eviter ce genre de soucis. L'application pourra etre recompiler quelque soit l'evolution de ma lib.

Je voulais jsute renforcer cette liaison avec un test de version a l'aide d'une constante definie dans l'unitee....

[korntex5]

désolé mais je pense que ta gestion de tes sources et des tes projets te mênera tôt ou tard à un crash, car tu risque de te mélanger les pinceaux voir de perdre des sources importantes sans possibilité d'annuler tout et de revenir à quelque chose de sûr...
Alors que si tu utilise la tortue tu arriveras toujours a retrouver tes feuilles de laitue...

je te conseille ce tutoriel:
http://hugo.developpez.com/tutoriels...version/#LII-2

après si tu trouve trop compliqué et pourtant ça ne l'est pas il existe d'autre logiciels...

[Clorish]

ok je vais voir de plus pres, des que j'ai 2 minutes

Par contre juste une toute petite question : la "tortue" permet elle de pouvoir lier directement diverses applciation aux unitees de versions differentes ? ou bien permet elle simplement de gerer une sorte de systeme de "rollback" ?

JE m'explique : J'ai cru comprendre que le systeme CVS permet de garder en memoire le parcours utilisé par les applications (versions) afin de revenir dans un etat precedent.
Mais qu'au final, le repertoire de travail reste toujour unique.
Dans ce cas je ne vois pas trop comment garder Plusieurs applciation en simultanées liés a differentes versions de ma lib.
Faire revenir ma lib a un etat anterieur pour recompiler uen ancienne application serait trop lourd.
Je suis deja oublige de faire ce genre de choses avec une DLL COM dont je doit enregistrer la bonne version avant chaques modification d'anciennes applications ...

[CapJack]

1) Compile ta dll en incorporant les informations de version (options de projet).

2) Au moment du lancement, extrais les informations de version de ta dll avec GetFileVersionInfo et VerQueryValue, et compare à la constante attendue. Si pas bon, Message d'erreur et Application.Terminate. Google est ton ami.

3) Optionnellement, si le nombre de fonctions disponibles dans la dll devait varier, déclenchant un message d'erreur en amont, utiliser un chargement dynamique, avec LoadLibrary & co, plutôt que statique, en aval de la vérification de version. Il doit y avoir des cours sur le site pour expliquer comment s'utilise LoadLibrary.

[Clorish]

C'est gentil capjack .. mais je crois qu'il y a erreur sur l'ennoncé
Je parle de librairie de developpement (serie d'unitees) et non pas de librairie binaire, au sens DLL du terme ....

merci quand meme

[CapJack]

Arg. Désolé. Ca me paraissait trop simple, aussi.

Pour ton problème, je ne vois pas de solution si ce n'est définir dans chaque unité une fonction renvoyant le numéro de version de l'unité.

[korntex5]

en fait si tu veux tu peux faire ainsi au départ voici ton tronc:

Code :

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

1
2
3
4
5
6
 
dossier mes projets
          dossier appli A en V1.0
          dossier appli B en V1.0
          dossier appli C en V1.0
          dossier code commun en V1.0

imaginons que tu fais évoluer ton appli A et que cela implique une évolution de ton code commun aussi puis tu commit tes modifs tu as ainsi cette arborescance:

Code :

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

1
2
3
4
5
6
 
dossier mes projets
          dossier appli A en V2.0
          dossier appli B en V1.0
          dossier appli C en V1.0
          dossier code commun en V2.0

maintenant imaginons que tu ai besoin de recompiler l'appli C pour corriger une erreur d'orthographe comme dans ton cas, il te sufiras dans windows de faire sur le dossier mes projets de faire click droit, puis dans les menus de turtoise de choisir de revenir à la révision que tu souhaite. automatiquement ton dossier deviendra par exemple:

Code :

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

1
2
3
4
5
6
 
dossier mes projets
          dossier appli A en V1.0
          dossier appli B en V1.0
          dossier appli C en V1.0
          dossier code commun en V1.0

ainsi tu peuxcompiler sans te poser de question.

Maintenant imaginons plus pervers, qe tu souhaite tester un nouveau développement dans ton code commun seulement pour l'appli C et que tu ne souhaite pas toucher à ta version 2, tu peux alors créer une branche appelée test qui aurra cette archithecture:

Code :

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

1
2
3
4
5
6
 
dossier mes projets
          dossier appli A en V1.0
          dossier appli B en V1.0
          dossier appli C en V1.1
          dossier code commun en V1.1

Finalement si tu souhaite intégrer à ta v2 les modifs de la V1.1 les menus de turtoise te permettent de fusioner la branche avec le tronc pour ainsi te retrouver en :

Code :

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

1
2
3
4
5
6
 
dossier mes projets
          dossier appli A en V2.1
          dossier appli B en V1.0
          dossier appli C en V2.1
          dossier code commun en V2.1

il est bien entedu que tu peux a tout moment tout annuler et revenir en arrière...

[Clorish]

oui je comprends. Et c'est ce que je craignait en fait.

Disons que sur le fond tu n'as pas tord, utiliser un CVS est ce qu'il y a de mieux et faudra bien que je m'y mette un jour. Mais il ne fait rien de plus que mes arborescences de repertoires :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Lib
    StdLib
        1.00
        1.01
        2.00
Project
    Appli_100
    Appli_101
    Appli_200

Je n'ai qu'a ajouter a mes chemins de recherche le bon repertoire et Zou ! je compile toutes mes applications quelques soit leur lib.
Par contre il me faut bien faire attention a bien lier les fichier, qu'il ny ai pas d'interferences avec les multiples endroit ou l'on peut specifier des chemins de recherches, etc .... D'ou l'idee de completer la technique par un test de versioning.

Si je doit avant chaques recompilation, retrouver et restaurer les bonnes version de lib, je pense que le remede est pire que le mal
Du moins, si je m'emploi ca sera pour d'autres raisons, notement au niveau du versionning des application (et non des libs).

[Clorish]

Pour ton problème, je ne vois pas de solution si ce n'est définir dans chaque unité une fonction renvoyant le numéro de version de l'unité.

Vi c'est ce que je fait .. et souhaite faire.
J'irais meme plus loin en disant que le versionning de la lib n'ets pas le plus important mais plutot celui de l'unitee.
Changer de version de lib a chaque fois qu'une unitee change ca risque d'etre lourd.

Il me manque juste un bon moyen de detecter les erreurs de versions ... si possible a la compilation.

Il n'existe pas un systeme de tests a la compilation qui entraine un echec de compilation ? ca serait cool .....

[korntex5]

voici en pièce jointe, chez moi mon arbre de révision qui maintenant est assez feuillu.

avec CVS tu n'as plus a réfléchir ou a modifier tes chemins tu aurras toujours l'arborescane ci-dessous avec juste les fichiers dans la bonne version:

Code :

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

1
2
3
4
5
6
7
8
 
mes progs
  Lib
      StdLib
  Project
      Appli_1
      Appli_2
      Appli_3

tu part de ton arborescance normale ou tout est compatible tu crée ton tronc
puis pour chaque projet tu crée une branche, ainsi chacun de tes projets peux évoluer différemment, et pour passer de l'un a l'autre tu ferme delphi tu commit tes dernières modifs, et tu saute tel un petit singe de la branche appli 1 à la branche appli 2, ainsi tout les fichier sont en config appli 2 et tu peux réouvrir delphi sur ton aplli 2 et compiler sans te poser de question de compatibilité ou autre....

Si un jour tu veux faire fusionner deux de tes projets c'est possible aussi.

les avantages sont nombreux car tu ne risque pas de te planter tu as un meilleur suivis de tes versions tu peux commenter chaques livraison de code, d'un seul coup d'euil tu voit quels sont les modifs que tu a faites, si au bout d'un certain temps tu veux tester l'existance d'un bug dans une version d'il y a 2 ans tu peux revenir dessus, si tu bosse avec d'autre tu te simplifie la vie au maximum...