Discussion :

[Idelways]

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



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

[Arwel]

Depuis que j'ai essayé Git, je ne peux plus m'en passer.

[gillai]

Depuis que j'ai essayé Git, je ne peux plus m'en passer.

+1.

Dans mon ancien job, CVS. Je n'ai utilisé que svn en stage et j'utilise git pour mes projets personnels.

[Firwen]

idem, Git est un poil plus délicat à prendre en main mais aprés c'est que du bonheur.

Décentralisé, reactif, simple à configurer, outils de merge puissants, parfaitement intégré à un environnement Linux/Unix,.....

Le seul défaut que je lui donnerai, c'est le plugin moisi associé pour eclipse

[gagaches]

perso, au niveau expérience, j'ai dans les pattes plusieurs années de gestion de config en clearcase/svn + connaissance de pvcs/dimensions, synergy.
je n'ai pas assez touché à Rational Team Concert (RTC) pour en faire une critique suffisante, même si pour moi, c'est l'avenir de ces outils.

Au final :
aucun n'est parfait.
mais surtout, avant les problèmes de l'outil, ce sont principalement les personnes qui ne savent pas l'utiliser.

Un outil de version de source (puisque csv/svn/git ne sont que cela) ne permet pas de gérer une configuration logicielle et tout le cycle de vie des bugs, anomalies, évolutions, releases/versions.

Je vois encore énormément de personnes utiliser svn avec 2/3 pauvres classeurs excel sans avoir un équivalent de jira/bugzilla/mantis/trac/... (jira est vraiment très fort là-dessus).

et c'est abérrant !

Bref, pour expliquer ceci :
- la gestion de commit hors connexion n'a AUCUN SENS ! le but d'un commit est de propager les modifications locales à un référentiel commun, partagé entre les développeurs (une branche, un projet, etc).
la personne est "hors connexion" -> elle n'a pas BESOIN de faire de commit.
Et faire un commit "hors connexion" qui se lance automatique à la première connexion est dangereux car le référentiel a pu évoler entre temps et qu'il est important de maintenir la cohérence du code livré.

- un commit est une propagation d'une version de fichiers à un instant donné. En phase de dev, il contiendra inévitablement des erreurs

- la difficulté lors des fusion de branche par contre, est tout à fait exacte. Pour voir une fusion de branche propre et efficace, c'est pour l'instant Clearcase le meilleur (je ne me prononce pas pour RTC).
Heureusement qu'on a des outils comme svnmerge qui permettent d'aider.
Mais comme les révisions ne possèdent pas de hiérarchie réellement établies, on ne pourra pas contrôler qu'une fusion d'une ancienne branche sur un tronc qui a évolué soit ok facilement (il faut repasser derrière à la mano).

- quant à la nécessité de déplacer les fichiers via les commandes svn, c'est évident qu'on est obligé de passer par là. C'est certes pénible pour le refactoring java par exemple, mais il n'y a pas d'autres moyens réels de déterminer dans un "working dir" si le déplacement manuel d'un répertoire correspond à une intention ou pas.

En fait, ceux qui sont contents avec leur svn/git/cie sont souvent des équipes de dev qui n'ont quasiment pas besoin de gestion de configuration logicielle.

Après, la méconnaissance du domaine de la gestion de config & l'attrait des technos blingbling font le reste.

Combien de projets sans PGCL (plan de gestion de conf logicielle) : qui ? quoi ? où ? comment ? juste définir simplement et proprement les règles de gestion, de création de branches, de gestion des livraisons, ...
Combien de lecteurs de cet article qui se diront, en lisant mon commentaire, "pff, mais c'est inutile, ce qu'il raconte ! moi je sais faire de toute façon et je me trompe pas".

[Firwen]

la gestion de commit hors connexion n'a AUCUN SENS ! le but d'un commit est de propager les modifications locales à un référentiel commun, partagé entre les développeurs (une branche, un projet, etc).
la personne est "hors connexion" -> elle n'a pas BESOIN de faire de commit.

Je ne partage pas ton avis.

Le but d'un commit est d'assurer une atomicité des transaction, de la même manière qu'avec un SGBD.

Un commit doit représenter un état donné des sources et si possible être réversible facilement, c'est tout.
D'autres avantages aparaissent lors de l'utilisation d'un réferentiel commun comme l'intégrité en cas de transactions concurrentes et c'est ce à quoi tu fais réference.

La notion de dépots "locaux" et de commit "locaux" que justement SVN ne gèrent pas contrairement à git ou hg, prend justement tout son sens en cas de travail sur des branches séparées sur gros projets.
Les dépots peuvent alors être redécoupés de manière hiérarchique et tiennent bien mieux la montée en charge.

En résumé je dirai que SVN c'est trés beau dans la théorie, git c'est beaucoup mieux dans la pratique.

[Killing Joke]

J'aurais pu être d'accord avec toi sur certains points, mais quand tu dis :

- la gestion de commit hors connexion n'a AUCUN SENS ! le but d'un commit est de propager les modifications locales à un référentiel commun, partagé entre les développeurs (une branche, un projet, etc).
la personne est "hors connexion" -> elle n'a pas BESOIN de faire de commit.

... je me dis que tu n'as peut-être plus qu'une vue assez éloignée des modes de développements aujourd'hui. Je bosse régulièrement hors connexion, et oui, j'ai BESOIN de faire des commit. C'est là où il y a une grosse différence entre GiT et CVS / SUBVERSION : CVS / SUBVERSION fonctionnement quasi-exactement pareils sur le principe. Mais un commit pour eux représentent : je fige les sources dans un état donné et je pousse tout vers le repository central.
Pour GiT, ce sont juste deux notions séparées, qu'on peut enchaîner ou non. Hors-connexion on ne fera bien sûr que le commit, et le "push" ne se fera qu'une fois la connexion retrouvée ET SURTOUT le push se fera vers où on veut : un repo' GiT central (pour moi c'est important d'en avoir un) OU un autre repository : par ex. celui d'un autre développeur, pour qu'il puisse récupérer un ensemble donné d'évolutions. Là çà comble un énorme manque de CVS/SVN : pour eux, un commit est forcément visible par tout le monde, en phases de dév' intensives, c'est parfois carrèment pas souhaitable ...

Du coup çà permet des choses complètement différentes de CVS / SVN et le comportement ci-dessus (commit personnels pour historisation) n'est PAS possible sous CVS / SVN (parce qu'il faut du réseau, et parce que çà impacte tout le monde). A la limite çà pourrait, pour comparaison, se faire si on pouvait poser des tags locaux sous CVS / SVN.


Sinon je plussoie les commentaires + hauts :
- GiT c'est bien ;
- mais c'est franchement + compliqué (quand même pas mal de notions et e manips' supplémentaires) ;
- le plugin Eclipse est très très insuffisant (dire que jusqu'à il y a peu, le .gitignore n'était pas pris en compte) ; aujourd'hui je le trouve encore méchamment buggé (j'ai un mal fou à le faire bien tourner avec Smart HTTP par ex., problèmes de droits, même sur les dernières versions de dév' du plugin) ;

Et en remarques supplémentaires :
- Smart HTTP pour GIT (git par HTTP et pas par SSH) est une vraie bonne nouvelle pour le projet : je n'utilise plus que çà (marche nickel de partout en ligne de commande, proxy d'entreprise ou pas) ;
- je trouve l'écosystème GiT assez sympa (mini-clients GiT en QT, interface web cgit très sympa, ...), surtout comparé à SVN / CVS (il y a des choses aussi, mais j'ai toujours trouvé le tout "pas très carré") ;
- par contre dans mon équipe de dév', clairement tout le monde n'est (et de loin) pas prêt à passer à GiT, parce qu'il y a des "vieux de la vieille" qui ne voudront pas changer et auront du mal avec GiT en ligne de commande (voir avec le plugin Eclipse) ET SURTOUT à cause de la catégorie des râleurs (les gens qui râlent tout le temps dès qu'on a changé qq'chose parce que çà ne marche pas toujours à 100% du premier coup ...). Plus le fait que tous les outils autours ne sont pas encore nativement compatibles avec GiT (Jenkins l'est par ex., Bamboo aussi mais le plugin n'a pas marché chez moi (sur une version un peu trop vieille de Bamboo), pas de pont JIRA <> GiT comme JIRA <> CVS, etc.)

Sinon je suis parti sur GiT et pas Mercurial ou Bazaar (qui ont tous deux aussi l'air très intéressants), pour la rapidité de GiT et ... la facilité d'installation (sur un PC Linux sans être root, grosses difficultés pour faire tourner Mercurial et Bazaar à l'époque où j'avais essayé).

Edit : +1 avec Firwen qui a répondu dans l'intervalle.

[Plageman]

Si les modifications ne sont pas propagées au serveur central, le commit n'existe pas.

Est-ce vraiment négatif ? Je suis dans un environnement avec peu de développeurs, et je trouve la gestion centralisée pratique : Facile pour les backups, et on sait où sont toutes les sources de tous les projets.
Comment sauvegarder à un endroit toutes les sources avec GIT si elles sont "éparpillées" ? Il faut faire confiance aux développeurs pour propager leur commit sur un dépôt qui servira de dépôt centralisé ou quelquechose dans le genre ?

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

C'est un défaut, mais un défaut qui me semble peu important : plus d'un jour sans connexion ou un serveur down plus de quelques heures, ça arrive ?

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.

Là je suis d'accord, c'est le plus gros défaut de Subversion...

Un autre point faible de Subversion serait la gestion nécessairement manuelle du système de fichiers.

C'est vrai que c'est pénible, même si les plugins dans les IDE permettent de ne pas trop y faire attention. Ce point va être amélioré dans la prochaine version 1.7 qui devrait sortir bientôt. Comment font GIT ou Mercurial pour faire la différence entre un ajout et un fichier renommé par exemple ?

[manudwarf]

Comment font GIT ou Mercurial pour faire la différence entre un ajout et un fichier renommé par exemple ?

Même empreinte SHA-1.

Sinon, THE truc qui me fait adorer git, le stash

[gagaches]

Désolé manudwarf, ça n'était pas mon intention d'être arrogant

<hs>faut imaginer mon environnement de travail depuis plusieurs années que je suis responsable de gestion de conf : CDS chez un grand compte, tout le monde "pond" à vitesse réelle urgente. Et ça foire. Donc je suis appelé pour venir passer derrière nettoyer la merde et leur expliquer quoi faire et comment faire, mais "veulent pas, ça prend du temps"/"maiseuh, on sait faire hein" . bref</hs>

Un commit doit représenter un état donné des sources et si possible être réversible facilement, c'est tout.

Pour moi, l'idée d'un commit, c'est :
1/ maj des sources via un référentiel commun
2/ on modifie une partie de ces sources
3/ les tests sont (enfin) ok
4/ on publie ces changements dans le référentiel (=commit)

Le sens du commit est de rendre permanent un changement temporaire.
L'inversion du commit dans git par rapport à cvs/svn (via le commit et le push) fait qu'on ne parle pas tout à fait de la même chose.
Le "commit" au sens publication = push dans git (et pas commit).

Le "commit" de Git dans le sens "sauvegarde/fixation des modifications" est une des sous-opérations atomiques d'un commit classique.

La notion de dépots "locaux" et de commit "locaux" que justement SVN ne gèrent pas contrairement à git ou hg, prend justement tout son sens en cas de travail sur des branches séparées sur gros projets.

Je veux bien que tu développes car je ne comprends pas ton point de vue :
le but des branches séparées + répertoire de travail est justement de permettre à chacun de travailler chez soi et de commiter "une fois" quand les tests sont ok.

Si on identifie des "bacs à sables", le fait d'utiliser plusieurs branches de développement à partir d'un référentiel commun (par exple, le tronc), divise déjà en plusieurs bacs à sables séparés qui permettent du dev parallèle/concurrent.
+ à partir de chaque branche, chacun se crée un répertoire de travail donc encore un "bac à sable" indépendant des autres.

Ce que je crois comprendre, c'est que tu(vous) voudrais pouvoir sauvegarder/figer plusieurs versions successives de ton code que tu développes chez toi (ce qui te permet de revenir ensuite facilement sur ce que tu as fais comme modifications) puis de ne faire qu'un seul commit en toute fin de dev, une fois que tout est ok ?

[martopioche]

- la gestion de commit hors connexion n'a AUCUN SENS ! le but d'un commit est de propager les modifications locales à un référentiel commun, partagé entre les développeurs (une branche, un projet, etc).
la personne est "hors connexion" -> elle n'a pas BESOIN de faire de commit.
Et faire un commit "hors connexion" qui se lance automatique à la première connexion est dangereux car le référentiel a pu évoler entre temps et qu'il est important de maintenir la cohérence du code livré.

- un commit est une propagation d'une version de fichiers à un instant donné. En phase de dev, il contiendra inévitablement des erreurs

Je me permet de réagir également sur ce point : la notion de commit dans un outil comme subversion correspond à la génération d'une version des sources ainsi qu'à leur publication. Dans un outil dit décentralisé, le commit ne consiste qu'à créer une version, la publication est une action à part. Non, "versionner" ne signifie pas "diffuser", surtout lorsqu'on s'intègre dans un flux d'intégration continue par exemple. En découplant version et publication, chaque développeur peut créer des versions cohérentes sans que cela ne déstabilise le projet en entier. Cela permet de faire plus facilement des branches "expérimentales" ou de se concentrer entre quelques développeurs sur une évolution particulière. Car l'autre avantage de la décentralisation est que chacun est un référentiel de sources.

Bref, tant qu'on reste attaché à l'idée commit = publication, on ne peut pas comprendre cette approche.

[martopioche]

On s'est croisé. Cas pratique sur ça :

1/ maj des sources via un référentiel commun
2/ on modifie une partie de ces sources
3/ les tests sont (enfin) ok
4/ on publie ces changements dans le référentiel (=commit)

Si j'ai implanté une fonctionnalité qui fait foirer les tests après un update, je vais devoir les corriger, mais cette correction va nécessiter de revoir ce que j'ai fait. Il serait bon d'avoir une version de ce que j'ai fait. Si je commit, la plate forme d'intégration continue part en erreur. Avec un commit local, j'ai la version de ce que j'ai fait qui marche, puis je peux me concentrer à la correction.

Edit : précision du cas :
- update
- réalisation de la fonctionalité
- Tout est ok
- sous SVN, je dois faire un update puis mon commit, je fais l'update
=> KO

Exemple sous Git, Mercurial, Bazaar...
- pull/update
- Réalisation
-> Ok
- Commit
- pull/update
-> KO
- Correction
- commit
- pull
-> Ok
- Commit/push

[Firwen]

grilled by martopioche

En résumé, je dirai que git permet un niveau de granularité sur les commits ( au sens large à la SVN ) que n'a pas SVN/CVS justement grâce au double système de commit/push et de dépots décentralisés.

[Plageman]

C'est vrai que d'après vos remarques, le "workflow" a l'air beaucoup plus souple avec GIT.
Mais il me semble qu'un point fort de Subversion, c'est son écosystème sous Windows : Existe-t-il un équivalent par exemple à Visualsvn Server, qui permet en quelques clics d'avoir un serveur Suvbersion configuré avec Apache et l'authentification windows intégrée (je suis développeur, pas trop de temps à perdre à installer et administrer un serveur.) ?
Est-ce que TortoiseGit est du même acabit que TortoiseSvn ?

[malkav1978]

J'utilise Subversion quotidiennement pour mon travail et je trouve qu'il remplit parfaitement sa tâche de système de contrôle de version. Comme le dirait Richard Fine dans son billet, Subversion est franchement meilleur que CVS (qui à d'ailleurs presque entièrement disparue là où je travail).

Dans la situation actuel, je ne suis pas un partisant de l'abandont de Subversion. Cela dit, je doit reconnaitre que mon expérience se limite CVS et, depuis quelques années, à Subversion. Surtout, je trouve certains des arguments de Richard Fine un peu léger, et un peu facile, pour prétendre que Subversion à fait son temps (et donc qu'il faut passer à autre chose).

Furthermore, because my commits are published as soon as they’re made, I have to be very careful about what I commit.

Filesystem operations like move and copy need to be ‘svn move’ and ‘svn copy’.

Dans ces deux cas, je trouve au contraire qu'un peu de rigueur ne fait pas de mal. Ces deux façons de faire fond partie de la philosophie de Subversion et cela permet de garantir qu'un commit ne contient pas n'importe quoi.

Je me demande du coup si les développeurs ne sont pas en train de tomber dans la facilité ?

[martopioche]

C'est vrai que d'après vos remarques, le "workflow" a l'air beaucoup plus souple avec GIT.
Mais il me semble qu'un point fort de Subversion, c'est son écosystème sous Windows : Existe-t-il un équivalent par exemple à Visualsvn Server, qui permet en quelques clics d'avoir un serveur Suvbersion configuré avec Apache et l'authentification windows intégrée (je suis développeur, pas trop de temps à perdre à installer et administrer un serveur.) ?
Est-ce que TortoiseGit est du même acabit que TortoiseSvn ?

Les SCM décentralisés se passent justement de serveurs. Git s'intègre mal à Windows (c'est toujours d'actualité me semble il), aussi je te conseillerai de t'intéresser à Mercurial pour lequel TortoiseHG est aussi complet que TortoiseSVN et de nombreux outils existent.

[codeAddict]

Pour moi SVN / CVS ne s'adresse pas à au même public que GIT, mercurial et co

Les premiers s'adressent à une clientèle professionnelle faisant du logiciel fermé sur des PC relié à travers un intranet. Ces gestionnaires de configuration s'adapte très bien aux méthodes de développement régie par une gestion de projet professionnelle.

Les seconds s'adresse à des projets open source développé au 4 coin du monde sujet des à fork et Co.

Non vraiment ce n'est pas la même chose....

[martopioche]

Dans ces deux cas, je trouve au contraire qu'un peu de rigueur ne fait pas de mal. Ces deux façons de faire fond partie de la philosophie de Subversion et cela permet de garantir qu'un commit ne contient pas n'importe quoi.

Je me demande du coup si les développeurs ne sont pas en train de tomber dans la facilité ?

Ce n'est pas qu'une question de rigueur, cf mon exemple plus haut (mais la formulation citée laisse plus cette impression).

Après, Subversion reste un bon outil malgré certains défauts qu'on peut lui reprocher, et le concept du commit est franchement l'un des plus mineur. Mais Subversion permet aussi des fonctions que les décentralisés ne permettent pas (lock modify unlock par exemple).

[nicorama]

Un outil de version de source (puisque csv/svn/git ne sont que cela) ne permet pas de gérer une configuration logicielle et tout le cycle de vie des bugs, anomalies, évolutions, releases/versions.

(...)

Bref, pour expliquer ceci :
- la gestion de commit hors connexion n'a AUCUN SENS !

(...)
Combien de lecteurs de cet article qui se diront, en lisant mon commentaire, "pff, mais c'est inutile, ce qu'il raconte ! moi je sais faire de toute façon et je me trompe pas".

Tu as l'air bien sûr de toi, et en même temps, tu donnes l'impression de ne pas savoir de quoi tu parles tellement c'est décalé.

Sur le sujet, je ne peux que conseiller d'écouter l'excellent épisode des cast codeurs dédié à git. Et bien sûr d'essayer Git ou Mercurial.

[gagaches]

[...]
Bref, tant qu'on reste attaché à l'idée commit = publication, on ne peut pas comprendre cette approche.

Sauf que le côté expérimental/sauvegarde des modifications en local n'entre pas dans le besoin de version logiciel.

En fait, je comprends mieux ce dont tu parles.
Mais un outil de version logiciel n'a pas pour but de sauvegarder les N version "foireuses" (désolé du terme).
Eclipse, notamment, permet de gérer au niveau local ce besoin de version de sources.

Le but d'un outil de version logiciel, c'est de sauvegarder les réelles nouvelles versions : correction d'un bug, évolution, nouvelle fonction, etc.

Le côté expérimental, tu le fais dans ton "working dir" ou sur une branche expérimentale que tu supprimeras une fois l'expérience finie.

+ parler de référentiels multiples n'a de sens que dans un projet open source qui n'a pas de réelle structure et où chacun bosse de son côté.

Ce principe ne peut pas s'appliquer dans un projet avec 25 développeurs sur une MC (maintenance corrective) + 3 projets d'évolution successifs conséquents en relation avec d'autres évolutions de logiciels connectés en //

Pourquoi on fait une version de source / configuration logicielle ?
pour stabiliser, identifier et contrôler le contenu des différentes versions successives d'un logiciel :
- Pour pouvoir dire que telle ano identifiée en prod en version 1.2.0.1 a été intégrée dans le lot de MC 1.2.1.1
- Pour pouvoir dire que le lot d'évolution 1.2.2.1 qui a démarré avec comme baseline la 1.2.0.1 doit prendre en compte les différentes MC entre la 1.2.0.1 et la 1.2.1.1 (soit toutes les 12.0.x)
- Pour être capable de regénérer la version 1.2.0.9 qui était en prod avant la montée de la 1.2.0.1 et tester sur cette version la 1.2.0.1
- Pour garantir que la 1.2.0.1 n'a pas embarqué une nouvelle fonction qui est toujours en cours de développement
- etc

Donc heureusement que chaque développeur n'a pas un référentiel chez lui comme avec Git

je vais être réaliste et "vache" : les besoins expérimentaux des développeurs, ils les font dans leur coin, en dehors de la gestion de config.

Pour vous donner une idée, les outils de gestion d'ano ont commencé à l'ano 00001.
On corrige actuellement les ano >14000 alors que le projet n'a que 5 ans.
Et là, la gestion de config ne contient QUE les versions "finalisées" après dev/test.

Non sincèrement, le plus important (et le plus gros problème), c'est le merge des branches, pas le "commit partiel"

Et @nicorama, c'est plus vos commentaires de "svn c'est nul, Git c'est trop bien" sans démonstration sur un projet réel qui me gêne.
La gestion de conf, j'en bouffe depuis 5+ ans maintenant et je réalise maintenant comme un développeur n'y connait rien au début ...