[SVN] question boulay?

question boulay? [SVN] - Divers - Programmation

Marsh Posté le 09-01-2008 à 10:16:08    

Dans le cadre d'un démarrage projet, nous étudions la possibilité de remplacer l'usage habituel de cvs par svn, là j'ai qques interrogations sur le sujet notamment :  
"SVN donne un numéro de version par commit"
En quoi ceci constitue t il un avantage? quelle est l'utilité d'avoir des numéros de version à chaque commit? la seule version intéressante d'une application n'est elle pas celle qui est qualifiée stable par l'équipe et digne de subir une recette ou un passage en production (version que nous taggions sous cvs)?
Si j ai bien compris, à chaque commit, l'ensemble des fichiers du référentiel voit son numéro de version incrémenté, donc par exemple dans le cadre d'une maintenance, des fichiers non impactées par une correction evoluent quand même en version?
 
un petit argumentaire de pro svn serait le bienvenu, merci!
 
 [:prettysmile]  [:prettysmile]

Reply

Marsh Posté le 09-01-2008 à 10:16:08   

Reply

Marsh Posté le 09-01-2008 à 10:46:44    

Si tu veux revenir en arrière, regarder le fichiers avant un commit, faut bien repérer le fichier dans le temps, nan ? Donc le numéro sert à ça.
 
Maintenant à chaque commit, y'a pas tous les fichiers qui changent de numéro, le numéro n'est valable que pour le repo et les fichiers modifiés par le dernier commit.
 
Enfin, c'est pas vraiment un numéro de version, mais plutôt un numéro de révision. Pour les numéros de version, à toi de gérer les tags comme tu le veux

Reply

Marsh Posté le 09-01-2008 à 11:26:15    

y a des tas de trucs sur svn meilleur que cvs ...
 
cvs versionne fichier par fichier
svn versionne commit par commit
 
etc

Reply

Marsh Posté le 09-01-2008 à 11:28:30    

prettysmile a écrit :

En quoi ceci constitue t il un avantage? quelle est l'utilité d'avoir des numéros de version à chaque commit?


Ca permet d'identifier l'état global de l'application à n'importe quel instant T au cours du développement du projet, chacun de ces instants T mappant sur une révision donnée.

prettysmile a écrit :

la seule version intéressante d'une application n'est elle pas celle qui est qualifiée stable par l'équipe et digne de subir une recette ou un passage en production (version que nous taggions sous cvs)?


Pour le client ou les managers peut-être, mais svn n'est pas un outil pour les clients ou les managers, c'est un outil pour les développeurs.

 

Pour les développeurs, toutes les "versions" du projet, stables ou pas, complètes ou pas, buggées ou pas, sont intéressantes et doivent pouvoir être identifiées.

prettysmile a écrit :

Si j ai bien compris, à chaque commit, l'ensemble des fichiers du référentiel voit son numéro de version incrémenté, donc par exemple dans le cadre d'une maintenance, des fichiers non impactées par une correction evoluent quand même en version?


Oui et non. Contrairement à cvs, svn n'a pas de concept de version d'un fichier. Le numéro de révision est global à tout le repository, on ne parle donc pas de "version 1.5 du fichier" comme dans cvs, mais de "fichier à la révision 2463", la révision 2463 portant sur l'intégralité du repository.

 

Il n'y a donc pas lieu de parler de "numéro de version" pour un fichier, et si un fichier ne change pas d'une révision à une autre alors il ne sera pas touché.

prettysmile a écrit :

un petit argumentaire de pro svn serait le bienvenu, merci!


  • SVN est notablement plus rapide que CVS (il fait transiter moins de données sur le réseau), et nombre d'opérations sont offline (diff et status, par exemple. Attention, cvs status et svn status n'effectuent pas exactement la même opération, l'équivalent précis à cvs status est svn status -u)
  • SVN a un diff plus efficace sur les fichiers binaires
  • SVN ne fait pas de keyword expansion par défaut (il faut le demander), il ne risque donc pas le corrompre un fichier binaire
  • Un commit svn est atomique, si on demande de commiter 5 fichiers alors soit ils seront tous commités dans la même révision soit aucun ne sera commité. Le résultat d'un commit est donc stable et sans surprises (sauf erreur de l'opérateur), même si e.g. le réseau tombe en cours de commit ou autre.
  • Les numéros de révision svn portent sur tout le repository, il est donc trivial de récupérer l'intégralité d'une version précédente du repo, dans sa totalité (build versioning, regression testing, ...)
  • Le contrôle d'accès de SVN est beaucoup plus pratique, puissant et flexible que celui de CVS, et on peut utiliser aussi bien un accès local que par le protocole svn:// (avec ou sans SSH) que par HTTP ou HTTPS
  • SVN conserve trivialement l'intégralité de l'historique des fichiers et répertoires, y compris quand on les renome, qu'on les déplace ou qu'on les clone (à ma connaissance, c'est impossible sous CVS, les opérations même ne sont pas native et quand on les fait manuellement on perd l'historique). Accessoirement, svn gère très bien la suppression de répertoires (il me semble bien que CVS a beaucoup de mal avec ça), la fait récursivement, et supprime lui même les fichiers et répertoires (pas besoin de rm -f avant de faire un svn rm, svn s'en chargera)
  • L'interface (en ligne de commande) de svn est, à mon avis, beaucoup plus simple
  • Les hooks svn sont infiniment plus simples à mettre en place et à gérer que ceux de cvs

Message cité 1 fois
Message édité par masklinn le 09-01-2008 à 11:29:17

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-01-2008 à 11:36:11    

et passer à SVN en 2008 serait une erreur ...

Reply

Marsh Posté le 09-01-2008 à 11:37:38    

masklinn a écrit :


Oui et non. Contrairement à cvs, svn n'a pas de concept de version d'un fichier. Le numéro de révision est global à tout le repository, on ne parle donc pas de "version 1.5 du fichier" comme dans cvs, mais de "fichier à la révision 2463", la révision 2463 portant sur l'intégralité du repository.
 
Il n'y a donc pas lieu de parler de "numéro de version" pour un fichier, et si un fichier ne change pas d'une révision à une autre alors il ne sera pas touché.


 
 
lu sur : http://www.pushok.com/soft_svn_vscvs.php

Code :
  1. Now you cannot tag a code, this function is simply missing. Certainly, to some extent this is compensated by universal numbering of files in SVN, that is, the whole repository gets the version number, but not each separate file


 
Dois je comprendre : plus  de n° de revision, uniquement des versions, à moi de retenir le n° de version livré, pas de tag permettant de surcharger ce n° avec le n° correspondant à la numérotation de l'application en production?

Reply

Marsh Posté le 09-01-2008 à 11:40:52    

A toi de gérer les numéros de version comme tu veux.

Reply

Marsh Posté le 09-01-2008 à 11:44:05    

Taz a écrit :

et passer à SVN en 2008 serait une erreur ...


pardon o_O

Reply

Marsh Posté le 09-01-2008 à 11:51:42    


Il manque un smiley dans son post, je pense que c'est ironique (cf. récentes discussion avec stallman, nan [:petrus dei] )

Reply

Marsh Posté le 09-01-2008 à 11:54:30    

FlorentG a écrit :


Il manque un smiley dans son post, je pense que c'est ironique (cf. récentes discussion avec stallman, nan [:petrus dei] )


 
ah ^^ je pensais qu'il avait écris SVN et penser CVS ^^

Reply

Marsh Posté le 09-01-2008 à 11:54:30   

Reply

Marsh Posté le 09-01-2008 à 11:56:41    

Taz a écrit :

et passer à SVN en 2008 serait une erreur ...


On est bien d'accord, mais c'était pas la question :o

prettysmile a écrit :


lu sur : http://www.pushok.com/soft_svn_vscvs.php

Code :
  1. Now you cannot tag a code, this function is simply missing. Certainly, to some extent this is compensated by universal numbering of files in SVN, that is, the whole repository gets the version number, but not each separate file



C'est incomplet.

prettysmile a écrit :

Dois je comprendre : plus  de n° de revision, uniquement des versions


C'est l'inverse, plus de numéro de version par fichier mais des numéros de révision portant sur le repository complet

prettysmile a écrit :

à moi de retenir le n° de version livré, pas de tag permettant de surcharger ce n° avec le n° correspondant à la numérotation de l'application en production?


Non. Par contre les tags sous SVN ne sont pas des objets à part (contrairement aux tags CVS) c'est une convention basée sur les fonctionalités de lazy copy de svn. Voir http://svnbook.red-bean.com/en/1.4 [...] .tags.html pour plus d'infos sur les tags (et je te conseille de lire tout le bouquin si tu veux réellement comprendre et évaluer svn)

FlorentG a écrit :


Il manque un smiley dans son post, je pense que c'est ironique (cf. récentes discussion avec stallman, nan [:petrus dei] )


Ben tu penses mal, il n'avait rien d'ironique (et il a raison pour 99% des cas imo)

Message cité 2 fois
Message édité par masklinn le 09-01-2008 à 11:57:00

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-01-2008 à 11:57:58    

masklinn a écrit :

Ben tu penses mal, il n'avait rien d'ironique (et il a raison pour 99% des cas imo)


Okay [:dawa] Alors tu fais référence aux DVCS j'imagine :)

Reply

Marsh Posté le 09-01-2008 à 11:58:06    

masklinn a écrit :


Ben tu penses mal, il n'avait rien d'ironique (et il a raison pour 99% des cas imo)


 
et donc faut faire quoi ?
 
(je suis rassuré j'y suis passé en 2k7 :E)

Reply

Marsh Posté le 09-01-2008 à 11:58:48    

Joel F a écrit :


 
ah ^^ je pensais qu'il avait écris SVN et penser CVS ^^


Suffit de faire une manip de branch avec SVN pour ce rendre compte c'est que exactement CVS - {syntaxe lourd}

Reply

Marsh Posté le 09-01-2008 à 11:59:29    

FlorentG a écrit :


Okay [:dawa] Alors tu fais référence aux DVCS j'imagine :)


ouaip. Enfin il fait référence, moi je ne fais qu'expliquer

Joel F a écrit :

et donc faut faire quoi ?

 

(je suis rassuré j'y suis passé en 2k7 :E)


C'est pas une question de "faut", c'est simplement qu'il existe maintenant des outils plus pratiques et plus modernes que SVN, mercurial ou git par exemple, qui sont dans une vaste majorité de cas des supersets du dit svn (ils en ont toutes les fonctionalités, et nombre d'autres en bonus)

Taz a écrit :


Suffit de faire une manip de branch avec SVN pour ce rendre compte c'est que exactement CVS - {syntaxe lourd}


En même temps, c'est malheureusement le but de svn, à la base. Un CVS en moins pourri :(

 

Donc même gestion des branches merdique :( :(
Et absence de merge tracking :( :( :(
(qu'ils songent enfin ajouter pour SVN 1.5 [:bien] c'est juste des années trop tard)

 

Par contre dans un registre plus joyeux, Darcs 2 arrive et apparement ils ont rêglé le conflict bug [:dawa]

Message cité 2 fois
Message édité par masklinn le 09-01-2008 à 12:02:01

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-01-2008 à 12:01:38    

masklinn a écrit :


C'est pas une question de "faut", c'est simplement qu'il existe maintenant des outils plus pratiques et plus modernes que SVN, mercurial ou git par exemple, qui sont dans une vaste majorité de cas des supersets du dit svn (ils en ont toutes les fonctionalités, et nombre d'autres en bonus)


 
je me rencadre alors. Le fait est que bon, je susi tributaire de mon hebergeur (sourceforge, donc bon).
Et surtout je me vois mal redire à mes colalborateurs : "on laisse tomber SVN pour XXX", 1 an aprés leur avoir dit "on lache CVS on fait du SVN" :o

Reply

Marsh Posté le 09-01-2008 à 12:02:37    

Joel F a écrit :

 

je me rencadre alors. Le fait est que bon, je susi tributaire de mon hebergeur (sourceforge, donc bon).
Et surtout je me vois mal redire à mes colalborateurs : "on laisse tomber SVN pour XXX", 1 an aprés leur avoir dit "on lache CVS on fait du SVN" :o


Quelle idée aussi d'attendre 2007 pour passer à SVN :D

Message cité 1 fois
Message édité par masklinn le 09-01-2008 à 12:03:08

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-01-2008 à 12:04:52    

masklinn a écrit :

(qu'ils songent enfin ajouter pour SVN 1.5 [:bien] c'est juste des années trop tard)


Ils songent, sur le très long terme, de faire du distributed aussi. Mais comme tu dis, ça ne sera par pour tout de suite, donc ça arrivera forcément trop tard, tous les autres DCVS seront complètement matures (s'ils ne le sont pas déjà...)

Reply

Marsh Posté le 09-01-2008 à 12:53:59    

masklinn a écrit :


Quelle idée aussi d'attendre 2007 pour passer à SVN :D


 
Ecoutes, je te raconterais par PM tellement c'ets humongous :o

Reply

Marsh Posté le 09-01-2008 à 13:03:18    

J'ai jeté quelques coups d'oeils ailleurs suite à votre discussion.
Arch ça vaut quoi ?

Reply

Marsh Posté le 09-01-2008 à 13:52:04    

FlorentG a écrit :


Ils songent, sur le très long terme, de faire du distributed aussi.


J'espère que c'est une plaisanterie, parce que c'est pas possible de passer un centralized en distributed correctement, c'est pas les mêmes principes, pas le même fonctionnement, pas le même workflow, et en bonus ça veut dire qu'ils perdent les locks [:pingouino]

Joel F a écrit :

Ecoutes, je te raconterais par PM tellement c'ets humongous :o


ok :o

gzii a écrit :

J'ai jeté quelques coups d'oeils ailleurs suite à votre discussion.
Arch ça vaut quoi ?


rien.

 

C'est un ancètre, et il est intéressant en tant que tel (d'un point de vue historique), mais c'est un DVCS de première génération à l'interface complètement imbitable et aux perfs pitoyables.

 

Aucun intérêt de se lancer dedans, au mieux il peut être intéressant à étudier si tu comptes créer un DVCS.

 

D'ailleurs, il est complètement à l'abandon depuis début 2006 (et son créateur et maintainer originel a conseillé de passer sur autre chose -- bazaar à l'époque -- quand il a quitté le projet)

 

edit: IMO, actuellement, les DVCS intéressants sont Git et Mercurial, avec Bazaar un peu en dessous, et Darcs à côté (des masses de fonctionalités agréables, des principes géniaux, mais de sévères bugs dans l'implé, entre autres).

Message cité 1 fois
Message édité par masklinn le 09-01-2008 à 13:56:43

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-01-2008 à 15:25:43    

Taz a écrit :

et passer à SVN en 2008 serait une erreur ...


y avait marqué boulay dans le titre...
Puis je bosse en SSII, lancer l'étude svn en 2008, c 'est déjà de l'innovation (pourquoi dépenser des sous pour remplacer qqchose que les gens savent utiliser?)
 
Je vais jeter un oeil à Mercurial et Git.
 
Merci pour vos réponses
 
 [:prettysmile]  [:prettysmile]

Reply

Marsh Posté le 09-01-2008 à 15:44:23    

Merci Masklinn pour tes conseils :)
 
Après lecture de quelques forums, je vais essayer Mercurial qui devrait me convenir.

Reply

Marsh Posté le 10-01-2008 à 11:37:23    

masklinn a écrit :


J'espère que c'est une plaisanterie, parce que c'est pas possible de passer un centralized en distributed correctement, c'est pas les mêmes principes, pas le même fonctionnement, pas le même workflow, et en bonus ça veut dire qu'ils perdent les locks [:pingouino]


C'est juste une phrase, jetée dans la roadmap :

Citation :

hybrid distributed/centralized VC model

 

Note que des mecs en ont fait une version distribuée (SVK). Je sais pas ce que ça vaut par contre

Message cité 1 fois
Message édité par FlorentG le 10-01-2008 à 11:37:29
Reply

Marsh Posté le 10-01-2008 à 11:47:14    

FlorentG a écrit :

Note que des mecs en ont fait une version distribuée (SVK). Je sais pas ce que ça vaut par contre


C'est moyen. Actuellement, il vaut mieux utiliser un bridge propre comme git-svn. J'ai essayé un peu svk et c'est chiant à utiliser.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 10-01-2008 à 12:13:28    

Remarque dans mon cas, j'aurais énormément plus d'interêt à utiliser Mercurial que SVN, vu que je bosse que sur portable, et ça m'arrive d'avoir pas de connexion.
 
Mon repo SVN est en local en fait [:dawa] J'aimerais bien le mettre sur le serveur, mais j'ai toujours voulu avoir une version localisée (si pas de connexion), mais j'ai jamais trouvé de système de réplication de repo pour SVN.
 
Donc en fait faudrait que je migre sous un DVCS...

Reply

Marsh Posté le 10-01-2008 à 12:14:59    

FlorentG a écrit :

Remarque dans mon cas, j'aurais énormément plus d'interêt à utiliser Mercurial que SVN, vu que je bosse que sur portable, et ça m'arrive d'avoir pas de connexion.

 

Mon repo SVN est en local en fait [:dawa] J'aimerais bien le mettre sur le serveur, mais j'ai toujours voulu avoir une version localisée (si pas de connexion), mais j'ai jamais trouvé de système de réplication de repo pour SVN.

 

Donc en fait faudrait que je migre sous un DVCS...


Ben ouais

 

edit: ou alors que tu foutes le repo svn sur le serveur et que tu joues avec git-svn, mais si t'as un contrôle total sur le bouzin autant passer totalement sous DVCS

Message cité 1 fois
Message édité par masklinn le 10-01-2008 à 12:15:28

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 10-01-2008 à 12:46:32    

masklinn a écrit :


Ben ouais
 
edit: ou alors que tu foutes le repo svn sur le serveur et que tu joues avec git-svn, mais si t'as un contrôle total sur le bouzin autant passer totalement sous DVCS


Tu joues ce que tu veux avec git-svn mais au moment où tu dcommit, ça applatira toutes tes branches/révisions locales.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed