Le projet PHP passe de CVS à Subversion, auriez-vous choisi le même gestionnaire de versions ?

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 ;)

Git est quand même le VCS du noyau Linux, ce qu'on peut considérer comme un gage de fiabilité et de support pour des projets massifs, en plus, sa gestion des branches est une pure merveille.
Et je pense que sa quantité d'utilisateurs, encore marginale, et sa complexité de mise en oeuvre et surtout d'utilisation ont du rebuter les core developpers de PHP.


J'estime par contre que Mercurial est à l'heure actuelle un concurrent sérieux à Subversion pour le contrôle de versions sur des projets de la taille de PHP. Pratiquement aussi mûr, sa gestion des branches est néanmoins beaucoup plus fine et subtile et surtout beaucoup moins lourde à gérer : les merges sont beaucoup plus aisés et ne nécessitent pas une copie complète de la branche comme c'est le cas pour SVN.
En plus, il est, comme git, décentralisé et par là même beaucoup plus résistant aux pannes.

Après, je ne conteste pas le choix de SVN : c'est l'un des plus répendus et des plus éprouvés avec CVS.

Pour l'avoir testé, pour sa simplicité d'installation et d'utilisation, pour sa portabilité, pour sa capacité a être utilisable hors ligne, mercurial est vraiment le meilleur VCS.

Mais c'est comme tout, bien qu'il y ai meilleur ailleurs on a du mal a changer ses habitudes.

http://blog.developpez.com/index.php...r_comme_system

Le soucis de Bazaar est sa TRES grande lenteur par rapport à Mercurial. Pour la plupart des opérations, il met pratiquement 2 fois plus de temps, et pour les plus lourdes il en met 10 fois plus.

Petit comparatif des temps mis pour effectuer des opérations entre Bazaar et Mercurial (pour les gens peu doués en physique, hg est le symbole atomique du mercure): (le comparatif date de 2006, ça a peut-être changé depuis, si vous en avez des plus récents, je suis prenneur)

repository initialization: hg 2.8x faster
hg: 0.67 seconds
bzr: 1.93 seconds

adding files for committal: hg 2.4x faster
hg: 1.12 seconds
bzr shared repository: 2.73 seconds

committing new files: hg 3x faster
hg: 4.08 seconds
bzr: 12.36 seconds

commit an append line to every file: hg 2.3x faster
hg: 8.63 seconds
bzr: 20.1 seconds

clone a repository: hg 4x faster
hg: 3.23 seconds
bzr shared repository: 12.92 seconds

committing in the cloned branch: hg 2x faster
hg: 10.6 seconds
bzr shared repository: 21.79 seconds

Initialize remote repository: hg 2.8x faster
hg: 5.71 seconds
bzr: 16.43 seconds

Push local repository to remote repository: hg 7.1x faster
hg: 11.38 seconds
bzr shared repository: 80.99 seconds

Branch from remote repository: hg 1.9x faster
hg: 8.16 seconds
bzr shared repository: 15.62 seconds (vanilla was 52.85 seconds)

Push appended line change to server: hg 10.1x faster
hg: 5.36 seconds
bzr: 54.62 seconds

Pull appended line change from server: hg 1.8x faster
hg: 9.65 seconds
bzr shared repository: 17.69 seconds (46.89 seconds for vanilla bzr)

source

bof... 2 à 4 fois plus lent pour des opérations en dessous de la seconde ca ne m'impressonne pas plus que ca.. surtout que les benchmarks datent de plus de 3 ans. les deux outils sortaient a peine de beta..

bazaar a pour lui launchpad. je crois pas qu'il existe d'equivalent pour hg.

enfin comme l'explique l'article que tu as donné, les outils sont similaire, ca ne me dérangerai pas de passer de l'un à l'autre

Alors oui, ça date, mais de nos jours encore, Bazaar a la réputation d'être plus lent que Mercurial (que ce soit avéré ou juste une rumeur galopant depuis l'époque des benchmarks que j'ai proposé).
J'ai eu vent de projets lancés cette année qui bien que préférant les possibilités offertes par bzr se sont tournés vers hg car repoussés par sa lenteur.
Cependant Bazaar a aussi des avantages que je ne renie pas : ça me fait une pause café pendant qu'il mouline :aie: (méchant le troll, méchant).

Après, c'est selon les gouts de chacun, je respecte parfaitement ton choix mais dans "mon cas intimement personnel" je lui préfère Mercurial pour sa réactivité.

(PS : si quelqu'un trouve des benchmarks plus récents, qu'il me les fasse parvenir, ça m'interesse beaucoup de voir l'évolution, et le cas échéant de voir que je me trompe)

Bonjou,

J'ai débuté avec subversion, parce que je n'avais pas le temps m'atteler à des test, car il à une réputation (bonne ou pas je vous laisse juge).

Cependant, étant encore novice dans le scm, je dois bien dire que la première fois que j'ai mergé mon projetr svn,
- 1 je me suis fait des frayeurs
2 - Mais qu'eeeeeeeeeessssttttt ce que c'était long... Surtout que j'avais pas le temps....

En faits, vous cité git, mercurial et bazaar ces outils vous apporte t'il un plus par rapport à cvs ou svn ? Je n'arrive pas bien à cerner leur domaines de compétences.

merci,
aplus

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.

me passer de cvs pour autre chose ?

=> à ça oui je l'aurais fait, et depuis un bail


maintenant svn ou un autre...

je suis utilisateur de svn depuis plusieurs années. Je l'aime bien, mais il a aussi ses défauts.

j'entends pas mal parler de mercurial à droite à gauche, mais jms testé perso. y'a de ca qq temps, j'avais d'excellents echos de perforce, mais bon à l'époque il était cher le coquin ;)

bref, mon 50 cent : oui j'aurais switché csv pour svn, trois fois oui

Citation:

---

Envoyé par Grabeuh

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

Citation:

---

Envoyé par Grabeuh

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.

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.

---

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

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.

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 :mouarf:

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

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

Citation:

---

Envoyé par Yogui

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 :mouarf:

---

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 ?

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 :mrgreen:

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.

Citation:

---

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