Developpez.com

Télécharger gratuitement le magazine des développeurs, le bimestriel des développeurs avec une sélection des meilleurs tutoriels

Qu'est qui ne va plus avec Subversion ?
Le système de gestion de versions est de plus en plus décrié et remplacé par d'autres outils

Le , par Idelways, Expert éminent sénior
Tout comme PHP, Subversion est en perte de vitesse ou en tout cas en perte rapide de popularité au profit d'autres systèmes de gestion de versions jugés plus dans l'air du temps, comme Git, Mercurial ou encore Perforce.

De plus en plus de développeurs l'abandonnent. Les plus blogueurs d'entre n'hésitent souvent pas à expliquer les raisons de leur infidélité dans des billets qui ressemblent étrangement aux nombreux plaidoyers qui expliquaient, il y a quelques années, les raisons du passage de CVS à Subversion.

Mais d'autres, plus remontés encore contre Subversion et ses utilisateurs (comme le développeur/blogueur anglais Richard Fine) n'hésitent pas à fustiger ses défauts et invitent les développeurs à le lâcher à leur tour. Une attitude qui peut être quelques fois (et hâtivement) taxée de harcèlement par les développeurs qui l'utilisent encore.

Le plus pénalisant des défauts de Subversion, d'après Richard Fine, est qu'il n'offre aucune séparation entre la création des commits et leur publication. Si les modifications ne sont pas propagées au serveur central, le commit n'existe pas.

Ce qui rend la création de commits hors connexion, ou lors de l'indisponibilité du serveur, tout bonnement impossible.

Subversion serait aussi sensible aux erreurs réseaux, notamment lors de la création de commits volumineux. La rectification de ces commits est d'après Fine fastidieuse.
Étant donné qu'il n'existe pas de commit sans publication, d'autres personnes peuvent utiliser ou reprendre les commits défectueux avant leur correction par d'autres commit...

Deuxième faiblesse de Subversion, et certainement la plus décriée : la difficulté de fusionner les branches, un domaine où subversion reste « fragile » même avec les dernières améliorations d’après notre blogueur.

Un autre point faible de Subversion serait la gestion nécessairement manuelle du système de fichiers. Il est nécessaire de passer par les commandes de Subversion pour les déplacer, copier ou supprimer sous peine de rompre l'historique des modifications ou de placer des fichiers là où ils ne devraient pas être.

Un point encore plus gênant lors de l’utilisation des IDE lourds et des autres outils de génération de fichiers.

Et vous ?

Quelles sont selon vous les faiblesses les plus pénalisantes de Subversion ?
Pensez-vous qu'ilne faille plus l'utiliser ?

Source : Billet de Richard Fine


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de engi engi - Membre régulier https://www.developpez.com
le 19/03/2011 à 17:30
Merci pour ces infos !

RADStudio = Delphi & C++ Builder = exotique ?
Avatar de NikeOfAllTrades NikeOfAllTrades - Membre à l'essai https://www.developpez.com
le 20/03/2011 à 11:35
Citation Envoyé par engi  Voir le message
RADStudio = Delphi & C++ Builder = exotique ?

Ho que oui.

Du Delphi et du C++ en 2011, exotique c'est le moins que l'on puisse dire.

En dehors de ça, n'utilisez pas Bazaar, c'est utilisé presque uniquement sur Launchpad et ça n'apporte rien par rapport à Mercurial ou git.
Avatar de ac_wingless ac_wingless - Membre confirmé https://www.developpez.com
le 20/03/2011 à 15:52
Citation Envoyé par Aéris22  Voir le message
TortoiseHG est dispo pour Mercurial, et TortoiseBzr pour Bazaar
TortoiseGit existe aussi mais Git et Windows ça doit bien faire au moins 42…
Des plugins existent pour les IDE «classiques» (Netbean, Eclipse…), mais je ne sais pas pour ton IDE qui me semble assez exotique.

Subversion est intégré dans RadStudio XE. Attention cependant, certains forums rapportent des problèmes de régression depuis 2010.
Par ailleurs, notre société utilise RADStudio depuis longtemps (BCB 2006) avec Perforce sans problème particulier, les fichiers inaccessibles étant de toute façon interdits en écriture.
Avatar de danucc danucc - Membre régulier https://www.developpez.com
le 23/03/2011 à 10:21
Moi j'utilise Bazaar pour sa simplicité et son efficacité.
Je n'ai pas comparé avec Git ou Mercurial mais par rapport à SVN j'ai beaucoup moins de problème entre versions du gestionnaire de version et surtout entre plateformes (Linux/Windows).

Danilo
Avatar de yrsone yrsone - Nouveau membre du Club https://www.developpez.com
le 23/03/2011 à 10:38
J'ai eu à administrer que 2 outils : Clearcase et SVN.

Première conclusion, le plus gros problème de ces 2 outils, il se situe entre le clavier et la chaise.

Clearcase est un outil très puissant (la gestion des merges et des streams miam) mais manipulé par des bourrins avec 2 mains gauches et qui ne comprendront jamais rien ... c'est une merde infâme qui peut partir en vrille pour un rien et qui peut devenir un enfer à débloquer. Administrer cet outil, plus jamais !

Comparé à Clearcase, SVN est certes moins puissant mais un véritable bonheur à remettre en marche en cas de problème.

Après en ce qui concerne Git & co, il faut du temps ... il faut faire bouger le mammouth (utilisateurs et décdeurs) et la mise en place d'un gestionnaire de versions peut être vécu comme une abomination apocalyptique par les "vieux", réfractaires à tout et qui ne comprennent pas pourquoi on ne peut plus directement développer sur les plateformes de production -> Ton outil, c'est de la merde !

Git est trop jeune et les interconnexions avec d'autres outils ne sont pas encore assurées donc dans certains cas, ca devient rédhibitoire.
Avatar de jljuan jljuan - Futur Membre du Club https://www.developpez.com
le 23/03/2011 à 10:48
Bonjour à tous,

Après avoir lu chacune de vos idées, je me permets de faire la synthèse suivante : ceux qui ont goûté à un DVCS ont du mal à revenir sur un VCS !

Effectivement, l'avantage du DVCS est de pouvoir avoir un dépôt local permettant l'activité "déconnectée" décriée de ci de là.

Quant à la gestion des branches et des fameuses fusions, ce n'est pas nouveau ! SVN part de loin et tente par tous les moyens de rendre la chose plus acceptable.
Mais encore une fois, la personne qui a goûté à un DVCS ne peut pas supporter/tolérer l'absence d'une gestion fine des changesets.

Alors oui, SVN est venu combler des défauts de CVS, mais il est arrivé aussi avec les siens .

Le besoin des utilisateurs a aussi évolué avec les outils : c'est heureux car c'est comme cela qu'on progresse tous.

Donc, après les modes SCCS, RCS, CVS, SVN, on avance vers Git, Hg, ... On passe du centralisé au distribué pour les besoins des projets : fini le temps du héros qui faisait tout dans son garage pour bâtir un empire.
Aujourd'hui, mener un projet au bout ne peut se faire sans une aide externe soit contrainte (near/off-shore pour les industriels) soit tout simplement de compétences distribuées de part le vaste monde.

Preuve en est l'évolution de ClearCase en mode multi sites en son temps.

Enfin, pour clore, il ne faut pas également oublier que la gestion en version de fichiers n'est qu'une partie de la discipline qu'est la Gestion de Configuration. Cette dernière donne un cadre de travail à une équipe, et si le héros résiste, c'est qu'il n'a pas intégré son objectif, d'où une certaine amertume et un refus du cadre imposé.
Le processus de gestion de configuration dicte les règles, l'outil reste et doit rester un outil, quitte à ce qu'il soit interchangeable durant le développement.

Il faut revenir aux bases, a-t-on nécessairement besoin d'une Ferrari pour aller d'un point A à un point B ?
Le code de la route est strict, pas plus de 90km/h sur nationale : une 2CV fait donc tout aussi bien l'affaire... et pour ceux qui pensent aux autoroutes : la vitesse minimale autorisée est 80km/h, certes ce sera bruyant en 2CV, mais gageons que nous atteindrons quand même le point B

Merci de m'avoir lu jusqu'au bout.
Jean-Louis.

PS : 14 ans de travail avec les outils VCS pour des grands comptes et de très nombreux utilisateurs/développeurs.
Avatar de mclane1 mclane1 - Membre du Club https://www.developpez.com
le 28/03/2011 à 11:39
En effet, par un système de "bonne pratique", on peut répondre au faiblesse ou bug de svn. Il suffit de les connaitre pour les éviter. Le développeur fait lui-même la fusion pour chaque commit, on ne commit que quand le serveur est dispo (y a pas le choix de toute façon) on commit le code d'un coté, et les autres données (spécifications/scripts/...) de l'autre.

Par contre, nous avons mis un système de compilation à la volé qui déconseille de commiter un code qui ne compile pas et dont tout les Test unitaire ne passe pas.

Je trouve donc dommage que pour le développement d'un code assez lourd, ca nous empêche de sauvegarder le travaille en cours de réalisation sans vraiment le mettre à dispo pour les autres.
Avatar de parrot parrot - Membre actif https://www.developpez.com
le 28/03/2011 à 17:05
Désolé de poser deux questions probablement triviales: étant de la vieille école (svn), je n'ai pas encore capté la philosophie des DVCS.

Qu'en est-il de la place nécessaire sur disque avec les DVCS? Si j'en crois le principe de Git, chaque développeur dispose de toutes les sources. Or, dans notre serveur SVN nous stockons tous nos projets. Cela signifie probablement quelques centaines de GB. Chaque développeur devrait-il avoir plusieurs centaines de GB sur son disque?

Deuxième question: comment les DVCS s'insèrent-ils avec l'intégration continue?
Avatar de jljuan jljuan - Futur Membre du Club https://www.developpez.com
le 28/03/2011 à 17:49
Citation Envoyé par mclane1  Voir le message
En effet, par un système de "bonne pratique", on peut répondre au faiblesse ou bug de svn. Il suffit de les connaitre pour les éviter.

Justement, les bonnes pratiques sont dans le Plan de Gestion de Configuration !! Faut bien les stocker qq part . Pour les pro-agile, un wiki fera tout aussi bien l'affaire !

Citation Envoyé par mclane1  Voir le message
Par contre, nous avons mis un système de compilation à la volé qui déconseille de commiter un code qui ne compile pas et dont tout les Test unitaire ne passe pas.

"déconseille" : pas mal comme concept !
La bonne pratique étant de ne remonter que ce qui compile et passe les tests.

Citation Envoyé par mclane1  Voir le message
Je trouve donc dommage que pour le développement d'un code assez lourd, ca nous empêche de sauvegarder le travaille en cours de réalisation sans vraiment le mettre à dispo pour les autres.

La bonne pratique est de travailler sur une branche privée dans l'attente d'une publication (fusion avec le travail des autres donc) lorsque les éléments ont atteint leur maturité. Donc, tu peux continuer à commiter sur ta branche et lorsque tout est prêt, tu peux fusionner...
Avatar de jljuan jljuan - Futur Membre du Club https://www.developpez.com
le 28/03/2011 à 18:14
Citation Envoyé par parrot  Voir le message
Désolé de poser deux questions probablement triviales: étant de la vieille école (svn), je n'ai pas encore capté la philosophie des DVCS.

Tu peux donc te tourner vers SVK qui est le DVCS sur base SVN.

Sans vouloir m'attirer les foudres de tous les aficionados des DVCS, je résume :
  • gestion des changesets : tous les changements sont vraiment isolées dans une transaction
  • réplication des dépôts : afin de pouvoir travailler en mode déconnecté ou sur des parties (branches, sous-ensembles, ...)
  • relation master/slave : à la fin, il ne doit en rester qu'un
  • mode déconnecté : tu peux enfin travailler sans avoir ton dépôt (master) sous la main


Citation Envoyé par parrot  Voir le message
Qu'en est-il de la place nécessaire sur disque avec les DVCS? Si j'en crois le principe de Git, chaque développeur dispose de toutes les sources. Or, dans notre serveur SVN nous stockons tous nos projets. Cela signifie probablement quelques centaines de GB. Chaque développeur devrait-il avoir plusieurs centaines de GB sur son disque?

Il serait peut être souhaitable de commencer à lui rendre du CPU en répartissant la charge, regarde du côté de svnadmin create/load...
De plus, rien ne t'impose de répliquer la base au complet. Tu peux très bien préciser une révision ou une branche.
De plus, tu cites "tous nos projets"; travailles-tu en même temps sur chacun d'eux ?

Citation Envoyé par parrot  Voir le message
Deuxième question: comment les DVCS s'insèrent-ils avec l'intégration continue?

Comme leurs camarades ! L'intégration continue n'utilise qu'une infime partie des possibilités des outils de gestion de versions (checkout essentiellement) alors qui peut le plus, peut le moins.
Il te reste à configurer ton outil d'intégration continue.
Avatar de Didjeko Didjeko - Futur Membre du Club https://www.developpez.com
le 24/05/2012 à 11:55
Cet article est étrangement écrit :
1. "De plus en plus de développeurs l'abandonnent", comme si le développement de logiciels était le fait d'un seul développeurs - ou un groupe de gens qu'on nomme communément "les développeurs", i.e. comme s'il n'y avait pas d'organisation hiérarchique d'équipes de développement, voire comme si cela n'existait pas - alors que c'est le cas général dans l'industrie du logiciel.
2. "Pour ceux qui l'utilisent encore" : c.f. point 1 et en plus l'idée sous-jacente que cela est inévitable voire souhaitable voire pressé. Hors temps et immédiateté... bof.
Est-ce qu'on parle à l'échelle d'un projet ou d'une organisation qui gère de nombreux projets ? A quelle échelle ? Changer ce genre de système ne se fait pas du jour au lendemain et peut prendre des années, c'est un projet en-soi.
Pour avoir travaillé dans de gigantesques structures, je trouve cet article extrêmement simpliste.
Offres d'emploi IT
Développeur Web FULL-STACK
VACALIANS GROUP - Languedoc Roussillon - SETE (34)
RESPONSABLE WEB ANALYTICS F/H
VACALIANS GROUP - Languedoc Roussillon - SETE (34)
Développeur WEB PHP F/H
VACALIANS GROUP - Languedoc Roussillon - SETE (34)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil