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!
 
   

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

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

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.

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.

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é.

• 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

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

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

 
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?

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

pardon o_O

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

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

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

C'est incomplet.

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

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)

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

Okay Alors tu fais référence aux DVCS j'imagine

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

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

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

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)

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 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

 
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"

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

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à...)

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

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

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

ok

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).

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
 
   

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

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

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.

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 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

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