Logiciel : Subversion 1.4.0 est disponible
Posté par David Anderson (page perso, ). Modéré le 20 septembre 2006.
Subversion est un système de contrôle de révision, développé dans le but de remplacer CVS comme norme du contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et développement sponsorisé par l'entreprise Collabnet, et regroupe maintenant une communauté très active. Un grand nombre de projets libres importants ont depuis migré vers Subversion et depuis quelques mois le grand hébergeur Sourceforge propose un hébergement sur Subversion, en remplacement de CVS.
Les avancées majeures de cette version sont l'apparition de l'outil svnsync pour synchroniser des dépôts, le support de BerkeleyDB 4.4 et des performances grandement améliorées aussi bien coté client que serveur. Et bien entendu, un nombre d'améliorations mineures et de corrections de bugs.
![[en]](../images/en.png)
L'annonce officielle (507 hits)-
Le site du projet (630 hits)
-
Les Release Notes (385 hits)
> Lire la dépêche (80 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #756341.
Run by 
Cette page a été générée par Templeet en 0.0845s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Vous devez entrer un sujet
Coté client, les fichiers .svn/entries ne sont plus en XML, et la copie de travail stocke plus intelligemment les propriétés des fichiers. Il en résulte un client Subversion capable de parcourir la copie de travail plus rapidement et efficacement.
Encore une belle preuve de l'aberration totale qu'est XML ... Quand j'entends que certains intaigristes veulent farcir /etc avec ce truc je perds tout espoir dans le genre humain.
[^]Re: Vous devez entrer un sujet
Tout a fait. Alors que le bon vieux format du .ini a la windows reste lui indetrone !
phil.freehackers.org
[^]Re: Vous devez entrer un sujet
Encore une belle preuve de l'aberration totale qu'est XML
Il ne faut pas confondre l'outil et son utilisation. XML est un outil très utile, il faut simplement refléchir à son impact au lieu de le choisir systématiquement.
[^]Re: Vous devez entrer un sujet
D'après moi, il est plus facile de développer un front end qui manipule un fichier XML que non XML. Lorsqu'un utilisateur utilise son éditeur texte pour modifier un fichier de configuration XML, le front end n'aura pas de difficulté pour prendre le relai, ce qui me semble bien plus difficile avec un fichier non XML.
Par exemple, si vous configurez un fichier à la "main" puis utilisez webmin pour configurer ce même fichier, votre fichier de configuration n'aura plus la même "tête".
Enfin, cela est mon analyse... peut être que je mon trompe... à vous de m'expliquer pourquoi.
[^]Re: Vous devez entrer un sujet
Pour les fichiers de configurations, il y a par exemple le format YAML qui est très bien, rapide et simple. Tu peux le travailler à la main (sous vi ou l'éditeur qui te plait) mais faire une couche graphique est aussi très facile.
Bref, il y a d'autres format que le XML qui sont aussi bien fichu.
Si tu te balades dans le CPAN, tu verras que tous les modules Perl ont maintenant un fichier YAML pour les décrire.
Mon choix est vite fait personnellement, je fais tous mes fichiers de configuration en YAML depuis que je l'ai découvert.
[^]Re: Vous devez entrer un sujet
Bref, il y a d'autres format que le XML qui sont aussi bien fichu.
Ca ne fait pas l'ombre d'un doute. Par contre, aucun format n'est aussi populaire que XML et aucun format ne propose donc une telle quantité d'outils associés. Je ne parle pas simplement de bibliothèques chargement/sauvegarde, mais aussi de tout le reste (validation de schéma, transformation, langage de requête, etc.).
[^]Re: Vous devez entrer un sujet
Le problème est que l'on ne parle pas ici des avantages de XML en général mais du cas particulier de subversion. Je suis d'accord pour dire que XML a des avantages dans certains problèmes mais pas dans tous.
Ici, pour subversion, il a l'air de s'agir essentiellement de sauver et recharger, par une seule application. Donc autant prendre un truc plus rapide que XML au moment ou l'API est stabilisé et marche.
Au niveau de YAML, j'aime bien l'exemple du CPAN car c'est un GROS machin avec des dépendances dans tous les sens et les fichiers descriptifs en YAML ont l'air de convenir à tous. Tant mieux.
[^]Re: Vous devez entrer un sujet
AMA Il est plus facile de développer un front-end qui manipule n'importe quel fichier structuré... si on a déjà une librairie existante qui fait le travail, et pour cela il y a le choix XML, YAML, JSON.... on doit pouvoir en trouver d'autres.
http://www.yaml.org/
http://www.json.org/
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: Vous devez entrer un sujet
Il faut comparer ce qui est comparable. Comparer XML avec quoi exactement? Quel autre format souple permet de stocker des données hiérarchiquement, de rendre ces fichiers lisibles à l'aide de tout un tas de front-ends sur tout un tas de plateformes, de rendre les fichiers de conf insensibles à ces p...tain d'aberrations syntaxiques (espaces vs TAB, espace avant le = ou non), de pouvoir utiliser des bibliothèques externes disponibles pour tous les langages au lieu de recoder un parseur à chaque fois, de gérer différents encodages, etc?
Parfois, il est préférable de perdre en performances à des fins d'interopérabilité, et je pense que c'est clairement le cas des fichiers de conf.
[^]Re: Vous devez entrer un sujet
tu peux essayer de regarder l'ASN/1 qui est fortement utilisé dans les telecoms.
C'est un format binaire pour lequel de nombreuses bibliothèques sont disponibles pour le rendre lisible et qui a l'avantage d'avoir une grammaire extensible et normalisée.
[^]Re: Vous devez entrer un sujet
Pour paraphraser arnaudus, l'avantage par rapport à quoi ? Parce qu'XML propose tout ça, même une version binaire (en cours de spécification par le W3C), et beaucoup plus encore...
[^]Re: Vous devez entrer un sujet
ah bin vivement la version binaire de l'XML alors, le seul "défaut" de l'ASN/1 est qu'il n'est pas en format texte comme l'XML.
L'ASN/1 a été optimisé pour la place prise, je me serais mal vu avec des tickets de taxe remontés des MSC (autocommutateurs dans le monde mobile) en XML... déjà que notre élément de médiation croulait parfois (rarement quand même) sous le nombre de TTfiles, si en plus la volumétrie avait été non optimisée /o\ (sachant que ce sont les I/O disques qui limitaient les perfs...). Un week-end nous avait permis de rattrapper un mois de consommations à une époque... (oui oui ça dépotait ;-) )
[^]Re: Vous devez entrer un sujet
<mode stroumph grognon> Moi j'aime pas les formats binaires </mode stroumph grognon>
Il faut que tu m'expliques en quoi ton format binaire 'achement vien foutu est tellement supérieur à XML qu'il peut se permettre d'imposer à l'utilisateur d'installer un soft pour le lire.
Parce que pour moi, la possibilité de se priver de
vi ~/.toto
:%s/blue/red/g
:wq
a un coût gigantesque.
Et XML, c'est, je paraphrase, C'est un format binaire texte pour lequel de nombreuses bibliothèques sont disponibles pour le rendre lisible et qui a l'avantage d'avoir une grammaire extensible et normalisée.
Ma (faible, je l'accorde) expérience m'incite à penser que la seule raison valable pour abandonner un format XML bien foutu, c'est quand les fichiers deviennent trop gros et que les accès sont trés fréquents, auquel cas il faut se tourner vers une structure de type base de données. Mais passer d'XML à un format binaire, ça me semble être un retour à la préhistoire. Même si je sais que mon opinion n'est pas vraiment partagée, je pense qu'un des avantages du gain de performances des machines, c'est aussi qu'on peut se passer de micro-optimisations désastreuses pour l'ergonomie et le développement.
[^]Re: Vous devez entrer un sujet
$ vi ~/.toto
bash: vi: command not found
Faut aussi installer un logiciel pour lire/écrire du xml de façon simple... Bon après c'est sur que c'est un seul éditeur de texte pour tous les fichiers xml, contre un par type de format binaire.
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Vous devez entrer un sujet
MFE detected !
(Mauvaise Foi Évidente)
[^]Re: Vous devez entrer un sujet
Bof, meme si je n'aime pas le XML (schema mal fichu, namespace pareil, etc..) l'avantage c'est que c'est rapide a utiliser car il y a beaucoup de librairie qui gerent ce format.
Donc cela me parait plutot une bonne idée de commencer par un format XML et s'il s'avere que c'est un probleme au niveau performance de remplacer par un format binaire.
C'est comme de commencer par developper en Ruby et remplacer si nécéssaire certaines parties par du C: une stratégie intelligente de developpement.
[^]Re: Vous devez entrer un sujet
schema mal fichu
Tu parles des schémas du W3C ou en général ? Parce que franchement, les schémas Relax NG, je ne vois pas en quoi ils sont mal fichus, au contraire.
[^]Re: Vous devez entrer un sujet
Du schema du W3C.
[^]Re: Vous devez entrer un sujet
C'est un dénigrement abusif du XML. Comme format d'échange entre applications, le XML a un véritable rôle à jouer. Par exemple, le protocole WebDAV est encodé en XML, ce qui permet a de multiples clients et serveurs de communiquer en utilisant un format parfaitement défini. Et c'est très bien.
Malheureusement, lors du développement de Subversion, le XML s'était aussi infiltré dans des fichiers qui ne sont lus que localement. L'idée était de pouvoir changer incrémentalement de format aisément, et de profiter de bibliothèques de lecture/écriture déjà très développées et performantes.
L'optimisation consistant à changer le format est venue suite à un effort de rendre toute la bibliothèque de gestion de copie de travail "streamy", c'est à dire opérant le plus possible sur des flux et des transformations de ces flux, plutot que sur le modèle "tout charger, modifier, tout ecrire". Et c'est là qu'un problème du XML se manifeste: il est difficile de lire seulement une partie d'un fichier sans d'abord tout charger pour avoir le DOM.
Le nouveau format s'affranchit partiellement de ce problème. De plus, maintenant que les métadonnées de copie de travail sont stabilisées et établies, l'extensibilité que promettait le format XML n'est plus vraiment utile. Une extensibilité plus limitée nous suffira jusqu'a Subversion 2.0.
Voila pour le raisonnement derrière tout ca.
[^]Re: Vous devez entrer un sujet
« Et c'est là qu'un problème du XML se manifeste: il est difficile de lire seulement une partie d'un fichier sans d'abord tout charger pour avoir le DOM. »
Je suis pas certaind e t'avoir bien compris, ie soit vous avez eu des pbs spécifiques au format choisi par svn qui vous obligeait à tout charger, auquel cas, c'est plus votre pb à vous qu'un pb de svn, soit tu te plains qu'en utilisant un parser xml DOM, on est obligé de tout charger, et là c'est un peu comme si tu disais "le pb avec un langage compilé, c'est qu'on est obligé d'avoir un compilateur avant de pouvoir exécuter le code".
Enfin tout ça pour dire qu'il y a des parsers XML permettant de ne parser qu'une partie du fichier et de t'arrêter quand tu en as envie, cf http://xmlsoft.org/xmlreader.html
Par contre, il est fort possible que si tu veux parser une partie du fichier, puis en réécrire uniquement une partie, alors ça ne soit pas super facile à faire.