Le projet PHP est passé de CVS à Subversion
Auriez-vous choisi le même gestionnaire de versions ?

Le , par Yogui, Rédacteur
Salut à tous,

Je me permets ce message d'information pour les amateurs de Subversion.

Le projet PHP va bientôt passer de CVS à Subversion. La nouvelle architecture est prête, les scripts de migration sont prêts :
http://marc.info/?l=php-internals&m=124567675723251&w=2

Le script de migration nécessite environ 18 heures pour traiter toute la base de commits CVS. L'idée est de passer la date de sortie de PHP 5.3.0, qui est l'une des plus grosses versions jusqu'à présent, et d'opérer la migration juste après cette date.

D'autres VCS ont été envisagés par le groupe, mais aucun ne semblait avoir la maturité de Subversion. C'est là que j'aimerais avoir votre avis : que pensez-vous de cette décision ? Quels VCS aujourd'hui permettent d'accueillir des projets de la taille de PHP, avec des développeurs issus d'horizons totalement différents ? Si vous pouviez répondre sans troller svp


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


 Poster une réponse

Avatar de kaymak kaymak - Membre chevronné http://www.developpez.com
le 08/07/2009 à 9:35
Citation Envoyé par Grabeuh  Voir le message
Les outils dont nous parlons sont des VCS décentralisés, permettant de travailler en hors ligne, de disposer de son "mini" repository en local puis de synchroniser avec un dépot distant.

Ils offrent tous des possibilités de branches plus évoluées que Subversion (travailler sur une branche est déjà complexe avec subversion, sur git tu peux en avoir 5 ou 6 simultanées sans aucun soucis, idem pour les deux autres dans une moindre mesure). Les merges sont aussi plus optimisées, moins longs et mieux pensés qu'avec SVN.

Etant dscentralisés, si le dépot principal tombe, tu peux avoir autant de dépot secondaire que tu veux avec ces trois outils, ce que SVN ne permet pas ou difficilement. La tolérance aux pannes en est grandement augmentée.

Ce sont les 3 points forts qui me passent actuellement par la tête, il doit y en avoir d'autres mais ils ne me viennent pas à l'esprit.

MH Effectivement !
Je comprend mieux vos choix, et ils rapportent tout à fait à mes craintes et frayeurs d'utilisateurs et (pseudo) administrateurs du dépôt.

J'ai plus qu'à ! Merci : )

a plus
Avatar de Yogui Yogui - Rédacteur http://www.developpez.com
le 08/07/2009 à 21:50
Citation Envoyé par Grabeuh  Voir le message
Etant dscentralisés, si le dépot principal tombe, tu peux avoir autant de dépot secondaire que tu veux avec ces trois outils, ce que SVN ne permet pas ou difficilement. La tolérance aux pannes en est grandement augmentée.

À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.
Avatar de kaymak kaymak - Membre chevronné http://www.developpez.com
le 09/07/2009 à 9:40
Citation Envoyé par Yogui  Voir le message
À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.

oui mais ta solution nécessite plus de moyens financiers (bon je sais, c'est pas le bout du monde deux serveurs à 50 euros).
Alors que si c'est décentralisé, effectivement, l'aspect redondant semble mieux gérés par les choix d'archi.
Reste à savoir si après il existe les outils nécessaire pour merger les versions distribuées et en faire naître un projet commun (cas où le serveur centrale tombe et qu'il ne reste plus que des versions clientes).

Par contre, le fail over, si cela te permet effectivement de ré attribuer dynamiquement une ip à une seconde machine.
Il me semble que ce procédé ne serait pas très adapté à ce process car comme c'est de la gestion de version, il faudrait, pour être iso, faire une copie instantanée des modifications sur le slave (un peu comme du mysql replication).
Ainsi seulement tu pourrais de permettre de faire jouer fail over sans que toi ni tes users ne se pose la question de la qualité du dépôt sur l'esclave.

A cause de cela, sur un svn, il est peut être plus intéressant de monter une bécane moloss sur du raid car cette technique me semble proposer une bien meilleure tolérance à la panne des dd.

D'ailleurs vous connaissez des gros dépot ? Ils ont des gros besoins de scaling (en nombre de clients) sur ces outils ?

fin voilà.

a plus
Avatar de Yogui Yogui - Rédacteur http://www.developpez.com
le 09/07/2009 à 20:48
Justement, la technique dont je parlais permet d'avoir une machine "copie permanente" avec la même IP, elle prend donc le relai dès que la 1° tombe. D'après ce que j'en ai compris, c'est l'OS qui s'occupe de toute la réplication et du réveil de la 2° machine en cas de panne de la 1° (je crois que c'est une question de pings fréquents de l'une à l'autre).

Le RAID est un autre système, c'est de la réplication au niveau du disque et non de la machine complète. Ce n'est pas incompatible, au contraire c'est en plus

Je crois qu'il est préférable d'avoir de la redondance matérielle (alimentation, disques, machines etc.) plutôt que de la réplication logicielle. C'est un plus coûteux à court terme mais on ne se pose jamais la question "où est la bonne version de mon code ?", donc sur le long terme je ne suis pas sûr que ce soit vraiment plus onéreux.
Avatar de Yogui Yogui - Rédacteur http://www.developpez.com
le 12/07/2009 à 2:09
Salut

Pour information, la migration est terminée :
http://cvs.php.net/viewvc.cgi/
http://svn.php.net/viewvc/

Avec au passage une réorganisation des répertoires, il était temps
Avatar de Grabeuh Grabeuh - Membre confirmé http://www.developpez.com
le 12/07/2009 à 4:59
Citation Envoyé par Yogui
À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.

C'est un exemple parmis tant d'autres de l'interet d'un système décentralisé, qui n'est pas non plus exempt de défauts. Et ce n'est pas son atout principal par rapport aux autres produits de versionning. Comme je l'ai dit, Hg, git et Bzr sont plus adaptés pour des projets qui vont nécessiter des développements parallèles de plusieurs branches, qui sont nettement plus simples à manier qu'avec SVN. Et c'est là leur principale force.
Le fait de pouvoir travailler en local sans avoir à dupliquer et synchroniser des repositories locaux et distants est aussi une différence fondamentale.

Cette tolérance aux pannes n'est pas une fonctionnalité désirée dès le départ, c'est une conséquence, certes bien pratique, du modèle décentralisé utilisé.
Et quitte à choisir un outil, autant en prendre un qui nous simplifie la vie au maximum sur des opérations lourdes, et qui en bonus nous évite de devoir déployer une solution de réplication en temps réel sur des serveurs.

Après, le choix d'un outil de versionning, c'est comme les gouts, les couleurs ou les OS : ça ne se discute pas.
Avatar de tripollite tripollite - Candidat au Club http://www.developpez.com
le 12/07/2009 à 11:24
Rien n'empeche de faire de l'ip failover sur un serveur avec mercurial.

Les SCM decentralisé ont toutes les fonctionnalité de SVN et plus.

On retrouve un excelent article sur linux magazine (http://www.ed-diamond.com/feuille_lmag118/index.html) page 42
Avatar de kaymak kaymak - Membre chevronné http://www.developpez.com
le 12/07/2009 à 11:28
Citation Envoyé par Yogui  Voir le message
Salut

Pour information, la migration est terminée :
http://cvs.php.net/viewvc.cgi/
http://svn.php.net/viewvc/

Avec au passage une réorganisation des répertoires, il était temps

En tout cas elle est pratique leur interface de navigation. Particulièrement ce select for diff.
D'ailleurs, quels sont vos interfaces web/local pour naviguer et tirer parti du dépot ? Je pense à smartsvn, ou websvn.

Git et mercurial utilise des outils complètement différent ?
Avatar de Grabeuh Grabeuh - Membre confirmé http://www.developpez.com
le 12/07/2009 à 14:47
Il me semble que des projets utilisant Redmine comme outil de gestion de projet peuvent disposer d'interfaces web pour SVN, Mercurial, Bazaar, git, CVS et Darcs. (Si Redmine est un terme inconnu pour vous, c'est un outil de gestion de projet, actuellement utilisé pour l'hébergement de projets proposé par Developpez)

Après, n'étant pas un utilisateur aguéri d'interface web pour mes dépots, je ne veux pas dire trop de bêtises. Mais il doit forcément exister des outils équivalents à websvn pour Mercurial ou git. Ou sinon, libre à votre imagination d'en créer un
Avatar de code barre invalide! code barre invalide! - Membre à l'essai http://www.developpez.com
le 30/07/2009 à 11:13
Bonjour,
en réponse à la question du post:
oui
et pourquoi?
Parce que subversion est répandu et donc accessible en langues et docs par des dev du monde entier. Techniquement il est complet, rien à redire de tigris.
Avatar de gtraxx gtraxx - Membre confirmé http://www.developpez.com
le 06/08/2009 à 12:07
Si Redmine est un terme inconnu pour vous, c'est un outil de gestion de projet

Une chose sur redmine, il ne faut pas oublier que la plupart des hébergeurs ne propose pas l'option "ruby" dans leurs packs.
Bien dommage, je le trouve vraiment pas mal
Offres d'emploi IT
Ingénieur qualité logiciel au CEPS H/F
Safran - Ile de France - Osny (95520)
Expert sécurité en audit d'applications (H/F)
Société Générale - Ile de France - Val-de-Marne
Software engineer H/F
Safran - Ile de France - Magny-les-Hameaux / Saclay

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