Astuce : Utiliser un contrôleur de version (SVN) depuis l'explorateur de fichiers (Windows)

Le 2006-10-17 11:53:03, par berceker united, Expert éminent

Bonjour,
Voila, voulant établire un certain suivi sur mes classes plus les methodes j'insere des numéro de version pour chacun d'eux. Ma question est de savoir sur quel critère on détermine une évolution de version. Quel est le format j'en vois plusieurs :
1.0.0.0 - 1.0 - 1.2.3. ça commence a partir de combien ? un ou zéro ?
Alpha => Beta => Release. pour ça j'ai compris.

Je developpe seul mais je pense que j'installerais subversion mais est-ce utile ?

Merci.

Discussion forum

44 commentaires

Mr N.
Expert éminent

Oui utilise subversion, même quand t'es tout seul. En tout cas c'est ce que je fais. Pratique pour savoir pourquoi j'ai fait telle ou telle modif, faire des diff entre différentes versions d'un script, ... Pratique aussi pour le prototypage (je suis à une version stable, je tente un truc en modifiant des fichiers, ça marche pas => svn revert et c'est marre). Bref, trop cool

Ensuite concernant le versionnage (1.0.3, ...) je le déconseille sur des fichiers. Réserve le plutot à des application ou composants entiers et indépendants.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs

Exemple : j'en suis à la 2.4.6
La prochaine version sera :
- 2.4.7 si je corrige un bug
- 2.5.0 si j'ajoute une ou plusieurs petites fonctionnalités qui ne modifie pas l'architecture
- 3.0.0 si je touche en profondeur l'appli (passage à PHP5, ajout d'une grosse fonctionnalité, ...)

A noter que plus tu as des versions, plus tu dois les maintenir.

le 17/10/2006 à 13:32
is_null
Inscrit

Si on estime une version à plus de 100 bugs, c'est une version alpha.
A moins de 100 bugs, c'est une beta.
Si la version du programme est potentiellement stable, on l'appelle Release Candidate.

le 17/10/2006 à 13:39
berceker united
Expert éminent

Envoyé par Mr N.

Oui utilise subversion, même quand t'es tout seul. En tout cas c'est ce que je fais. Pratique pour savoir pourquoi j'ai fait telle ou telle modif, faire des diff entre différentes versions d'un script, ... Pratique aussi pour le prototypage (je suis à une version stable, je tente un truc en modifiant des fichiers, ça marche pas => svn revert et c'est marre). Bref, trop cool

Ensuite concernant le versionnage (1.0.3, ...) je le déconseille sur des fichiers. Réserve le plutot à des application ou composants entiers et indépendants.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs

Exemple : j'en suis à la 2.4.6
La prochaine version sera :
- 2.4.7 si je corrige un bug
- 2.5.0 si j'ajoute une ou plusieurs petites fonctionnalités qui ne modifie pas l'architecture
- 3.0.0 si je touche en profondeur l'appli (passage à PHP5, ajout d'une grosse fonctionnalité, ...)

A noter que plus tu as des versions, plus tu dois les maintenir.

- Etant donné que je suis "encore" sur windows je vais tenter de trouver une version tournant dessus. Zend studio semblerais gérer Subversion.
- Merci c'est ce que je voulais savor. Je pense que je prendrais ta façon de déterminer les évolutions de numéro. Je ne voulais pas le faire sur les fichier mais sur le classe et les methode de cette même classe. Ceci me permet d'avoir une précision étant donnée que je developpe entièrement en objet ceci afin que je ne rate rien. Surtout que je pose des commentaire à la norma java (phpdoc...).

Envoyé par is_null

Si on estime une version à plus de 100 bugs, c'est une version alpha.
A moins de 100 bugs, c'est une beta.
Si la version du programme est potentiellement stable, on l'appelle Release Candidate.

Merci j'y penserais mais dans les testes unitaire de chaque classe dans la mesure du possible mais cela me fait penser qu'il faut qu'il faut je mette noir sur blanc les test à faire et les resultats attendu afin de déterminer si c'est concidérer comme stable ou non.

Harf!.. tenter de monter un projet propre ça nécessite beaucoup de chose.
Au passage, je pense que je vais utiliser un outil de gestion de projet tel que DotProject qui m'a l'air pas trop mal quoi que un peut "usine à gaz"

Merci à vous mais c'est la bienvenu s'il y a d'autre contribution.

le 17/10/2006 à 13:54
Mr N.
Expert éminent

Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en local A moins bien sur que tu héberges proprement tes sources sur un sourceofrge/trac ou similaire.

Par contre je persiste à penser que c'est une mauvaise idée de tagger des fichiers/classes individuellement. M'enfin, c'est personnel tout ça, tu verras bien par toi même à l'usage
Sinon n'oublie pas que tu peux mettre des $Id$ (et autres mot clés) dans tes commentaires. Ainsi à chaque revision ils seront substitués et donc tu sauras quand et qui a modifié le fichier et quelle est sa révision.

le 17/10/2006 à 14:06
kankrelune
Membre éclairé

Envoyé par Mr N.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs

Je fonctionne de la même façon... c'est la manière normale de faire... par contre pour les alpha,beta,etc je ne fonctionne pas pareil... pour moi la version d'un script qui a plus de 100 bugs potentiel c'est même pas encore une alpha... .. .

@ tchaOo°

le 17/10/2006 à 14:16
berceker united
Expert éminent

Envoyé par Mr N.

Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en local A moins bien sur que tu héberges proprement tes sources sur un sourceofrge/trac ou similaire.

Par contre je persiste à penser que c'est une mauvaise idée de tagger des fichiers/classes individuellement. M'enfin, c'est personnel tout ça, tu verras bien par toi même à l'usage
Sinon n'oublie pas que tu peux mettre des $Id$ (et autres mot clés) dans tes commentaires. Ainsi à chaque revision ils seront substitués et donc tu sauras quand et qui a modifié le fichier et quelle est sa révision.

Pourquoi c'est une mauvaise idée?
La version principale sera sur celui du fichier donc la classe vu qu'il y a un fichier par classe.

le 17/10/2006 à 14:18
kankrelune
Membre éclairé

Envoyé par berceker united

Pourquoi c'est une mauvaise idée?
La version principale sera sur celui du fichier donc la classe vu qu'il y a un fichier par classe.

Je dirais comme Mr N... à partir du moment ou le fichier n'est pas indépendant il n'est pas utile de lui donner un numérot de version vu qu'il dépend de(s) script parents et donc hérite de leur numérot de version... par contre si ton script/classe est un script indépendant, genre plugin, là tu peux lui donner un numérot de version perso... .. .

C'est plus logique, ça donne moins de taf et allège le suivi des versions... .. .

@ tchaOo°

le 17/10/2006 à 14:33
berceker united
Expert éminent

Envoyé par kankrelune

Je dirais comme Mr N... à partir du moment ou le fichier n'est pas indépendant il n'est pas utile de lui donner un numérot de version vu qu'il dépend de(s) script parents et donc hérite de leur numérot de version... par contre si ton script/classe est un script indépendant, genre plugin, là tu peux lui donner un numérot de version perso... .. .

C'est plus logique, ça donne moins de taf et allège le suivi des versions... .. .

@ tchaOo°

Ok je comprend. Donc en gros je peux le faire à deux niveaux. Dans le fichier / class/ methode Juste pour moi pour mon suivi d'évolution personnel mais pour subversion je gère les versions au niveau des modules qui est ensemble de scripts.

le 17/10/2006 à 15:36
Mr N.
Expert éminent

Attention à ne pas confondre "version" et "revision".
La "revision" correspond à un commit. Un numéro de révision est attribué automatiquement à tout le repository (à la différence de cvs où c'est fichier par fichier).
Quand à la version, ça correspond à la branche sous cvs, attribué manuellement par le developpeur/chef => X.Y.Z

le 17/10/2006 à 15:47
berceker united
Expert éminent

Envoyé par Mr N.

Attention à ne pas confondre "version" et "revision".
La "revision" correspond à un commit. Un numéro de révision est attribué automatiquement à tout le repository (à la différence de cvs où c'est fichier par fichier).
Quand à la version, ça correspond à la branche sous cvs, attribué manuellement par le developpeur/chef => X.Y.Z

Ha effectivement c'est pas la même chose et il ne faudrait pas que je me base dessus en parlant de la révision. La version je voudrais la poser moi même.

Je pense qu'en utilisant subservion j'y verrais plus claire car là pour l'instant cela me parait peut être un peut trop abstrait pour que je puisse décider quoi faire.

le 17/10/2006 à 17:01

Poster une réponse