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

[Invité]

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.

[Invité]

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]

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.

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

[Invité]

[...]
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 ...

[martopioche]

Aïe... Non, ce ne sont pas les même notions (mais venant d'un utilisateur de Clearcase ça ne m'étonne pas )

Eclipse, notamment, permet de gérer au niveau local ce besoin de version de sources.

Faux, Eclipse gère des versions de fichiers, pas de sources. Une version de sources est l'état de l'ensemble de tes fichiers (pour SVN, Git, Mercurial, Baraar...). Comment peut tu restaurer l'état de tes sources à la modification n donnée d'un fichier avec l'outil d'Eclipse ?

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.

Oui et non. Pour cela, il y a les tags et les liens vers les versions spécifiques dans les outils de suivi de tickets.

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

Au contraire, un exemple de théorie : http://martinfowler.com/bliki/FeatureBranch.html

Pour le reste, tu confond version de sources (qui trouve sa place dans un gestionnaire de sources) et version logicielle (qui est le tag d'une livraison). Sans ajouter la caricature du projet OpenSource ( = non structuré). Sans prôner la multiplication des versions à outrance, versionner souvent permet d'isoler les modification. Si tu dois versionner uniquement l'ensemble du travail fini, tu a plus de chance d'introduire, d'amplifier, et de rendre difficilement identifiable un "bug" (je veux rester générique).

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

On ne va pas se les comparer, mais je rajouterai que beaucoup de développeurs n'y comprennent rien tout court. Pas la peine d'être au début ou plus loin. Pour la plupart, gérer une version consiste à exécuter un update/commit en priant qu'il n'y ai pas de merge. Le sens derrière...

[Legion.nux]

Perso niveau pro... on est passé de Cvs à Svn... le changement a déjà été douloureux pour certains... habitudes tout ça... Cependant, finalement assez deçu par Svn... bien plus véloce c'est certain mais plus-value pas fantastique et surtout merges assez douloureux...
Les plugins eclipse ne sont pas si merveilleux que cela voir même assez lourdingues (démarrage eclipse, ...)

Niveau perso j'ai essayé quelques dvcs... première expérience avec Bazaar que je trouvais déjà pas mal, même si un peu fouillis sur certaines fonctionnalités (repo central,...), puis je suis passé à Git et c'est vrai qu'une fois la phase d'apprentissage passée... il fait vite oublier Svn. J'aimerais bien qu'il soit adopté niveau pro mais bon déjà vu le temps qu'il a fallu pour passer de Cvs à Svn... c'est pas demain la veille.

Après les goûts et les couleurs c'est l'affaire de chacun... mais bon les DVCS permettent de nouveaux comportements, notamment dans le dev collaboratifs (github, bitbucket, ...) et au final ça en devient presque plaisant...

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.

heu un noyau Linux par exemple, ça fait assez réel ??
Je taquine

[Invité]

Aïe... Non, ce ne sont pas les même notions (mais venant d'un utilisateur de Clearcase ça ne m'étonne pas )

Gestionnaire de conf clearcase stp :p

Effectivement, à force d'avoir des outils hyper rigides et structurés, ma pensée se rigidifie.
Rien que pour les derniers commentaires, je suis content d'avoir discuté sur ce sujet ici (j'ouvre ma vision et je vois d'autres approches différentes).

Faux, Eclipse gère des versions de fichiers, pas de sources. Une version de sources est l'état de l'ensemble de tes fichiers (pour SVN, Git, Mercurial, Baraar...). Comment peut tu restaurer l'état de tes sources à la modification n donnée d'un fichier avec l'outil d'Eclipse ?

tu ne va pas tout restaurer en une fois et je ne dis pas que c'est facile
Si tu as ce genre de conflit au niveau des sources, tu as besoin d'un mécanisme de lock/modify/unlock (comme dans clearcase par exemple).
Pour l'instant, les choix de création de branche sont suffisamment bien faits pour n'avoir que très rarement ce genre de problème.
(cf. plus bas).

Au contraire, un exemple de théorie : http://martinfowler.com/bliki/FeatureBranch.html

très intéressant.

Pour le reste, tu confond version de sources (qui trouve sa place dans un gestionnaire de sources) et version logicielle (qui est le tag d'une livraison). Sans ajouter la caricature du projet OpenSource ( = non structuré). Sans prôner la multiplication des versions à outrance, versionner souvent permet d'isoler les modification. Si tu dois versionner uniquement l'ensemble du travail fini, tu a plus de chance d'introduire, d'amplifier, et de rendre difficilement identifiable un "bug" (je veux rester générique).

non, je ne confonds pas. Je parle intentionnellement de version logicielle car la version de sources en est un sous-produit. L'ensemble des révision de SVN est inutile si on est incapable d'associer ces révisions à des corrections et donc des versions spécifiques des différents composants de notre application.

Au niveau du dev, c'est pour permettre du travail concurrent qu'on crée les branches.

Sauf que l'intelligence fait que, dans une branche, le travail est beaucoup plus rarement concurrent.
les besoins de dev font qu'on peut se synchroniser et développer dans les quelques composants communs impactés un dev après un autre.
suffit juste de communiquer un peu

On ne va pas se les comparer, mais je rajouterai que beaucoup de développeurs n'y comprennent rien tout court.

tiens, on dirait qu'on a les mêmes développeurs :p

----------------
Je ne quote pas mais je rebondis/réponds au commentaire d'Aéris22 qui montre différents usages que je trouve très intéressant, notamment sur l'aspect intégration/revue de code.

Pour l'instant, il n'y a aucun SCM qui permet de valider facilement l'intégration de plusieurs lots de dev en production :
le temps entre la livraison et la MEP est trop important pour être atomique
-> les méthodes passaient souvent par des branches d'intégration puis merge dans le tronc (merdique & souvent illisible)

C'est vraiment le point qui pèche :
on est capable de se baser sur un référentiel et de créer plusieurs lots de développement.
on est déjà beaucoup moins capable de merger proprement ces différents lots selon leur MEP et donc de propager l'évolution du référentiel aux autres développements en cours.

Clearcase a une solution "simple" : il est tellement rigide qu'on n'a pas le choix, il râle si on n'est pas à jour.

SVN à l'inverse est beaucoup trop souple et permissif.
Et ça devient le bordel quand on a n composants avec m développement en cours (n x m branches sur lesquelles propager les modifs, c'est pas gagné).

Donc, cette solution de "triple" repository avec push sous git est très élégante :
- 1 repository pour le dev
- 1 repository pour l'intégration/release (on peut passer l'IC, les tests, intégrer plusieurs devs séparés, etc, et donc au final, accepter ou rejeter la livraison)
- 1 repository final public qui représente la production

A voir pour industrialiser la chose mais c'est très intéressant, je trouve !

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

[Traroth2]

mais surtout, avant les problèmes de l'outil, ce sont principalement les personnes qui ne savent pas l'utiliser.

Voila exactement le problème : ces outils sont souvent trop complexes à utiliser. Un bon outil est un outil qui sait se faire oublier. Un développeur a (ou devrait) avoir d'autres préoccupations que d'apprendre à utiliser des outils compliqués.

Personnellement, j'ai utilisé CVS, SVN et maintenant Git, et Je préfère Git, car il retombe toujours sur ses pieds en cas de problème (pour l'instant en tout cas). Mais à certains moments, il ne fait pas immédiatement ce que je veux, et je suis obligé de me plonger dans la documentation pour que ça marche, et je n'ai tout simplement pas que ça à faire ! C'est un distraction de ce qui constitue mon véritable travail : l'ingénierie logicielle. Analyser des problématiques, trouver des solutions techniques, concevoir des solutions logiciels, les réaliser ou les faire réaliser. Voila mon métier. Pas me prendre la tête avec un logiciel qui n'est pas capable de me laisser faire simplement ce que j'ai besoin de faire !

[ac_wingless]

On peut aussi se demander pourquoi Perforce est en train de gagner du terrain par rapport à SVN (ou SVN est en train d'en perdre par rapport à Perforce...) alors qu'ils sont très proches fonctionnellement.

Et si une partie des problèmes de SVN étaient moins fondamentaux que ceux mentionnés dans cette discussion? Après tout, Perforce est pénible pour les fusions de branches, mais avec les superbes outils de merge et de micro-inspection lors des merge, on s'en sort très bien. Perforce ne distingue pas commit de push, mais avec il est (presque trop) simple d'embarquer en réunion une copie locale du dépôt, et de refusionner les commits (qui deviennent donc "locaux" par magie) au retour. Pareil pour les renommages, fort lourds sous Perforce: on peut les rendre relativement indolores par des filtres de vues.

Donc je pense que les problèmes de SVN viennent plus de ses outils que de ses problèmes fondamentaux. Sinon, personne ne paierait 800$ par an par poste pour Perforce, qui ne propose rien de mieux dans son principe.

On a eu récemment un stagiaire qui ne jurait que par Mercurial. Il avait raison sur toute la ligne, mais il a bien été forcé d'utiliser Perforce, et a découvert la simple "time-lapse view". Rien que ça lui a fait admettre que ça valait la peine de se faire c... avec un vieux truc pourri, parce qu'au bout du compte, nous sommes là pour faire notre travail le plus efficacement possible, pas pour respecter des principes de travail les plus élégants possibles. Alors quand SVN combine de vieux principes de travail avec des outils dépassés, il ne faut pas s'étonner de son sort.

[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