Discussion :

[Yogui]

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

[Grabeuh]

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.

[tripollite]

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.

[mamelouk]

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

[Grabeuh]

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

[mamelouk]

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

[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

[Grabeuh]

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

[tripollite]

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

[kaymak]

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 ?

[Grabeuh]

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

[code barre invalide!]

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.

[gtraxx]

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