Discussion :

[jljuan]

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.

[mclane1]

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.

[parrot]

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?

[jljuan]

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 !

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.

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

[jljuan]

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

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 ?

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.

[Didjeko]

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.