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

Membre éclairé

Le 16/03/2011 à 14:36

Envoyé par gagaches

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

4

0

Firwen

Membre expérimenté

Le 16/03/2011 à 13:44

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

3

0

Firwen

Membre expérimenté

Le 16/03/2011 à 14:04

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.

4

1

Killing Joke

Membre actif

Le 16/03/2011 à 14:10

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.

3

0

martopioche

Membre éclairé

Le 16/03/2011 à 14:40

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

Envoyé par gagaches

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

3

0

martopioche

Membre éclairé

Le 16/03/2011 à 18:29

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

)

Envoyé par gagaches

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

3

0

Aéris22

Membre du Club

Le 16/03/2011 à 21:40

Ce qui manque énormément à SVN, c'est très clairement la notion bien distinct de commit / publication qu'apportent les DSCM*comme Git et Mercurial.

J'ai au moins 2 ou 3 cas bien concrets d'application où je ne pourrais plus me passer de telles fonctionnalités.

* Développement sans serveur disponible

Obligation d'utiliser du bon vieux CP-OLD, impossible d'obtenir une autre révision que celle sur le poste (par exemple de visualiser une branche en cours de dev), d'effectuer plusieurs commit bien distincts (tout sera commiter avec le message «Trajet Paris-Brest» une fois revenu au bureau)

Avec SVN, impossible de travailler dans le train durant un déplacement pro avec 4h de trajet.
Impossible aussi de commiter des correctifs effectués lors d'une réunion avec le client (méthodes agiles exclues d'office!) voire de réaliser un tag pour une livraison si on n'est pas au bureau.

Cas plus atypique, le travail à la maison! Avec SVN*et sans VPN, mission impossible.

* Modifications multiples ayant du sens globalement mais pas atomiquement

J'ai plusieurs exemples où il est intéressant d'avoir la distinction commit / push.

Le cas de la correction de bugs où je sépare généralement la correction proprement dite du rétablissement des tests unitaires (qui peut prendre plusieurs heures), afin de pouvoir faire une revue de code efficace sans être pollué par des diff de reprise de test. Ceci permet aussi de pousser le bugfix chez les autres devs qui en ont besoin rapidement sans attendre les tests U qui arriveront le lendemain (merci les DSCM!) sans pour autant plomber l'intégration continue (pour l'ensemble des autres devs et jusqu'au lendemain…).
C'est uniquement quand le couple code + test U est opérationnel que je pousse le tout sur le serveur central pour donner à manger à la CI.

Autre cas à la con avec SVN (qui a déjà été mentionné ici), je dev un bugfix, je remet d'équerre les tests. Tout marche chez moi, mais quelqu'un a fait un commit entre temps sur le dépôt.
Version avec SVN, je veux commiter je ne peux pas, il faut que j'update et que je mélange du merge avec du commit de bugfix sous peine de casser la CI. Aucun traçabilité, tout est mixé (code métier, code test, code merge), pour revert le bugfix sans perdre le merge, c'est mission impossible.
Pire, le merge pourrait faire l'objet d'une branche à part entière pour restaurer l'application, mais il sera trop tard après le update, tout sera déjà mixé et pas de commit du bugfix…
Version DSCM, je fais 2 commit (code + tests U), j'update, je merge et je commit, puis je pousse le tout. 3 commits, simple à tracer et sans mélange d'objectifs sans rapport entre-eux. Niveau traçabilité il n'y a pas mieux.

* Intégration et revue de code

Comment mettre en place du filtrage efficace par revue de code avec SVN? Impossible, le développeur devra commiter dans le dépôt public pour demander une relecture et son code est accepté *a priori*. Si le code est rejeté, le mal est déjà fait, tout est déjà updaté sur tous les postes de dev et tout le monde va se manger un revert et un merge…
Et avec le grave problème du merge de SVN, impossible d'envisager des branches pour chaque relecture!
Alors qu'avec un DSCM, il envoi son code dans le dépôt d'intégration du release manager, qui l'acceptera ou pas dans le dépôt public (read-only!). L'acceptation est *a posteriori* et un rejet ne pénalise personne!

3

0

jljuan

Futur Membre du Club

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.

3

0

Arwel

Nouveau membre du Club

Le 16/03/2011 à 13:21

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

2

0

Plageman

Membre régulier

Le 16/03/2011 à 14:21

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 ?

2

1

Identifiez-vous

Créer un compte

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

Identifiant
Mot de passe

Mot de passe oublié ?