Articles précédents : Logiciel
- [54] La correction grammaticale sous Linux x86 avec Antidote
- [15] Sortie de Acceleo 1.1
- [57] Mythtv 0.20
- [72] À la (re)découverte de Zsh
- [57] Sortie de Tellico 1.2
- [40] L'offre des jeux sous GNU/Linux continue de s'étendre
- [171] Rentrée des classes pour GNOME 2.16
- [26] Linux-VServer : Nouvelle version stable, nouveau site Web
- [31] cdrkit : Debian forke cdrtools
- [0] Prométhée 5.0
Liens connexes
- L'annonce officielle (500 hits)
- Le site du projet (618 hits)
- Les Release Notes (378 hits)
Dépêche modérée par
Dépêche éditée par
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 (500 hits)-
Le site du projet (618 hits)
-
Les Release Notes (378 hits)
> Lire la dépêche (80 commentaires, moyenne: 3,1).
L'amélioration la plus visible pour les utilisateurs est sans doute l'apparition d'un nouvel outil, svnsync. Comme son nom semble l'indiquer, cet outil permet de créer des miroirs d'un dépôt Subversion, et de gérer la synchronisation de ces dépôts. Ce n'était possible jusqu'a présent qu'en utilisant des scripts qui ne pouvaient pas garantir l'atomicité des opérations, et qui comportaient beaucoup de bidouilles pour permettre de synchroniser de façon fiable. Svnsync utilise une nouvelle API qui permet de s'affranchir de ces bidouilles, et qui sera sans aucun doute très appréciée par d'autres projets ayant besoin de reproduire à distance des copies parfaites d'un dépôt.
L'autre bonne nouvelle, pour les administrateurs de dépôts cette fois, concerne les dépôts utilisant une base BerkeleyDB: Subversion 1.4.0 supporte maintenant BerkeleyDB 4.4. Cette nouvelle version résout le plus gros problème qu'ont les administrateurs de dépôts BDB, en gérant automatiquement le rétablissement d'un dépôt qui a souffert d'une déconnexion brutale. Exit donc les utilisations répétées de 'svnadmin recover' pour faire taire les erreurs suite à une opération malheureuse, BDB le fera tout seul lors de l'opération suivante.
Enfin, pour l'utilisateur et l'administrateur, Subversion 1.4.0 est une version focalisée sur la performance.
- 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. Le nombre d'inodes requis pour gérer une copie de travail est aussi réduit, pour le plus grand bonheur de développeurs travaillant sur de gros arbres de code source ;
- Coté serveur, le format de stockage des deltas entre versions a été revu, et il en résulte un gain important de place, pouvant aller jusqu'a 50% de poids perdu pour certains fichiers. Il est par contre nécessaire d'effectuer un cycle svnadmin dump/svnadmin load pour pouvoir tirer parti de cette amélioration, sinon Subversion continuera d'utiliser l'ancien format de deltas.
Les autres améliorations moins vastes que l'on peut trouver sont:
- Le serveur svnserve peut maintenant fonctionner comme service (équivalent d'un daemon unix) sous Microsoft Windows, sans avoir à recourir à des scripts externes ;
- Sur MacOS X, le client svn utilise KeyChain pour stocker son cache de mots de passe au lieu de .subversion/auth/ ;
- Le moteur de diff interne à Subversion peut maintenant ignorer les différences en nombres d'espaces/tabulations et en formats de fin de ligne, pour des diffs qui vont à l'essentiel de ce qui a véritablement changé ;
- Les commandes 'svn diff' et 'svn merge' ont une nouvelle option permettant de demander le diff/la fusion d'une seule révision: 'svn diff -c 1234' est l'équivalent de 'svn diff -r1233:1234'.
L'avenir
Avec son adoption par Sourceforge, et plus récemment par Google pour son hébergement de projets libres, Subversion s'établit de plus en plus comme le remplaçant de fait de CVS. Ce n'est pas une raison pour se reposer sur ses lauriers, et les développeurs ont une assiette bien remplie pour l'avenir.
Dans quelques semaines se tiendra le premier SVN Summit. Hébergé par Google en Californie, cette rencontre sera l'occasion pour beaucoup de ces développeurs de se rencontrer pour la première fois (!), et de discuter sur la future direction de Subversion.
L'un des grands sujets du sommet est le support de suivi de branches ("Merge Tracking"), fonctionnalité réclamée depuis longtemps et déjà bien avancée dans la version de développement. Les autres sujets de discussion sont très variés, allant d'une refonte du schéma de représentation d'historique à des témoignages sur des utilisations ésotériques de Subversion.
Il y sera également question de la roadmap vers Subversion 2.0, la première version qui pourra se permettre de briser la compatibilité avec les versions 1.x pour améliorer la structure du logiciel et y faire un grand ménage, corrigeant des problèmes qui n'avaient pu être adressés avant à cause de la politique de compatibilité agressive du projet.
A noter
Cette version est déjà disponible dans Slackware current, soit la (très) prochaine Slackware 11.0 (nous en sommes à la rc5).
-
[^]Re: A noter
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:06. (lien). Évalué à 1.Merci de cette précision! Signalons également que les paquets debian doivent déjà être dans unstable, le mainteneur des paquets les avait prêts avant que je n'annonce la sortie officielle!
Contrôle de révision.
Cette manière de dire ressemble fort à une traduction littérale et mauvaise de l'anglais, ça n'a pas vraiment de sens...
Enfin au moins je ne comprend pas ce qui peut se cacher derrière ce terme de "cntrôle de révision", pour moi ça ne veut rien dire.
Franchement, mieux vaut soit laisser le terme anglais, soit utiliser une traduction convenable en français, sinon il faut vaguement retraduire littéralement en anglais pour comprendre...
D'ailleurs, une bonne traduction se trouve aisément, tu as mis directement un lien wikipédia vers "contrôle de révision" qui redirige vers la page de "gestion de versions" qui sans être une manière transcendante de décrire le logiciel, à l'avantage d'être compréhensible, en français.
Yth.
-
[^]Re: Contrôle de révision.
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:09. (lien). Évalué à 4.C'est un point intéressant que tu soulèves. Merci d'avoir fait la recherche, ça fait un moment que je cherche une traduction de revision control.
Notons néanmoins que "gestion de versions" peut induire en erreur, parce qu'on utilise souvent "version" pour parler de sorties stables d'un logiciel, plutot que les changements incrémentaux qui prennent place pendant le développement. C'est pour cela que Subversion préfère en anglais "revision control", plutot que le "version control" que CVS utilisait.
Alors, "gestion de révisions" ? Moyen encore, puisque ca peut se comprendre comme "outil pour gérer son bac". La langue française est mal fichue des fois :-)-
[^]Re: Contrôle de révision.
Posté par gnu_thomas () le 21/09/2006 à 05:43. (lien). Évalué à 0.Dans le même genre :
des problèmes qui n'avaient pu être adressés
est un anglicisme.
Enfin, on pinaille car ta news est claire et complète :)-
[^]Re: Contrôle de révision.
-
-
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
Posté par Philippe Fremy (page perso, ) le 20/09/2006 à 09:34. (lien). Évalué à 6.Tout a fait. Alors que le bon vieux format du .ini a la windows reste lui indetrone !
-
[^]Re: Vous devez entrer un sujet
Posté par boubou (page perso, ) le 20/09/2006 à 09:36. (lien). Évalué à 10.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
Posté par Stéphane KLEIN (page perso, ) le 20/09/2006 à 10:51. (lien). Évalué à 4.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
Posté par Sytoka Modon (page perso, ) le 20/09/2006 à 11:37. (lien). Évalué à 5.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
Posté par boubou (page perso, ) le 20/09/2006 à 13:13. (lien). Évalué à 2.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
Posté par Sytoka Modon (page perso, ) le 20/09/2006 à 15:47. (lien). Évalué à 3.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
Posté par Laurent Pointal (page perso, ) le 20/09/2006 à 11:52. (lien). Évalué à 5.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/
-
-
[^]Re: Vous devez entrer un sujet
Posté par arnaudus () le 20/09/2006 à 11:11. (lien). Évalué à 4.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
Posté par baud123 (Jabber id, page perso, ) le 20/09/2006 à 12:52. (lien). Évalué à 4.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
Posté par boubou (page perso, ) le 20/09/2006 à 13:15. (lien). Évalué à 0.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
Posté par baud123 (Jabber id, page perso, ) le 22/09/2006 à 19:06. (lien). Évalué à 2.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
Posté par arnaudus () le 20/09/2006 à 16:18. (lien). Évalué à 2.<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
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 20/09/2006 à 21:32. (lien). Évalué à 1.$ 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
-
-
-
-
-
[^]Re: Vous devez entrer un sujet
Posté par reno () le 20/09/2006 à 11:15. (lien). Évalué à 5.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
Posté par boubou (page perso, ) le 20/09/2006 à 13:16. (lien). Évalué à 2.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
-
-
-
[^]Re: Vous devez entrer un sujet
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:15. (lien). Évalué à 6.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
Posté par Christophe Fergeau () le 21/09/2006 à 08:03. (lien). Évalué à 1.« 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.
-
Bouquins sur Subversion
Pour ceux qui souhaitent utiliser/passer à subversion, et qui veulent un livre en français, il y en a au moins un chez deux éditeurs de référence : O'Reilly et Eyrolles.
O'Reilly propose la traduction francaise du "SVN Book", Version Control with Subversion, intitulé en francais "Gestion de projets avec Subversion". http://www.oreilly.fr/catalogue/2841772691.html
C'est un livre très théorique, relativement complet. Sorti en novembre 2004 et donc basé sur la version 1.2 de Subversion. Vous pouvez vous faire une idée du contenu (en anglais par contre) sur le site http://svnbook.red-bean.com/en/1.2/index.html car le SVN Book est sous licence CC-by il me semble. (à vérifier par les experts sur http://svnbook.red-bean.com/en/1.2/svn.copyright.html ). Le passage à la version papier est plutôt réussi.
Quant à Eyrolles, le livre "Subversion, Pratique du développement collaboratif avec svn" http://www.editions-eyrolles.com/Livre/9782212119190/subvers(...) est lui aussi une traduction d'un livre anglais, celui de Mike Mason "Pramatic version control using Subversion. Il prends une orientation différente du livre précédent: il est plus axé pratique avec quelques cas d'utilisations concrets décrits (ce n'est pas pour autant un cookbook !). Il va moins dans les détails et les subtilités mais donnera toutes les clefs pour une utilisation quotidienne et une aide à l'administration. La version anglaise se base sur la version 1.2, mais lors de la traduction, les traducteurs ont mis à jour pour une utilisation en 1.3
Personnellement, pour avoir lu les deux, je recommanderais l'Eyrolles à quelqu'un qui débute ou n'a que quelques notions d'un gestionnaire de version et j'orienterais l'utilisateur quotidien de CVS ou autre outil similaire vers l'O'Reilly.
-
[^]Re: Bouquins sur Subversion
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:18. (lien). Évalué à 3.Merci pour ces précisions! J'ajouterais juste que le "SVN Book" édité par Oreilly tient lieu de documentation officielle du projet. En tant que telle, elle peut parfois être trop détaillée. Le livre d'Eyrolles est un livre écrit par l'un des développeurs, se focalisant lui sur une approche didactique, quitte à passer sous silence des détails ésotériques.
Bref, les deux ont leur utilité. Je recommanderais également le Eyrolles à des gens cherchant une introduction à Subversion. Pour ceux qui veulent un ouvrage de référence, l'Oreilly est à préférer. Sa version originale en anglais est disponible sur le web, sous une licence creative commons: http://svnbook.red-bean.com/ .
Compatibilité ascendante
Question : j'ai un serveur Mandriva 2005 qui tourne avec subversion 1.1.4, est-ce que je peux tout de meme utiliser la version 1.4 sur les postes clients, ou est-ce que cela peut poser des problemes ?
Faut-il toujours une équivalence entre la version du serveur et celle des clients, ou est-ce que c'est assez souple ?
-
[^]Re: Compatibilité ascendante
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:23. (lien). Évalué à 3.J'ai répondu, en catimini, dans le détail de la dépêche: la politique de compatibilité de Subversion est très stricte de ce coté là: pour toute combinaison existante de x et y, un client 1.x peut communiquer avec un client 1.y .
Donc, ton client 1.4 peut sans problèmes communiquer avec un serveur 1.1.4. Bien entendu, les fonctionalités coté serveur seront limitées à celles présentes dans Subversion 1.1, et tu ne bénéficieras pas de quelques optimisations du protocole de communication. Mais tout devrait toujours fonctionner, sinon c'est une régression.
Le jour ou Subversion 2.0 sortira, il n'y a aucune promesse autre que "Il sera possible de passer de 1.x a 2.0 d'une façon ou d'une autre". Les clients 1.x ne pourront vraisemblablement pas communiquer avec un serveur 2.0.
[+] OpenCVS
Juste pour info, si subversion est le successeur de CVS, cela implique qu'il va le remplacer: je n'en suis pas convaincu
a) CVS est largement utilisé et tout le monde ne vas pas passer à subversion
b) un projet OpenCVS est démarré chez openBSD, qui paraît-il va être utiliser pour les sources d'openBSD.
-
[^]Re: OpenCVS
Posté par Florent Zara (Jabber id, page perso, ) le 20/09/2006 à 11:08. (lien). Évalué à 5.Juste pour info, si subversion est le successeur de CVS, cela implique qu'il va le remplacer: je n'en suis pas convaincu
a) CVS est largement utilisé et tout le monde ne vas pas passer à subversion
Le but de Subversion est de fournit un remplacant inconstestable à CVS, pas de démarcher les projet pour leur demander de changer et d'abandonner CVS en le remplacant par SVN.
Ils offrent le choix en proposant une alternative proche (pour simplifier, on peu facilement remplacer cvs par svn dans les commandes) et comblant les lacunes du premier à la communauté Open Source. En effet, beaucoup de solutions propriétaires offraient des solutions de gestion de fichiers puissantes et fonctionnelles avec peu ou pas d'équivalent dans le monde du libre.
je cite le site de subversion : "The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community."
b) un projet OpenCVS est démarré chez openBSD, qui paraît-il va être utiliser pour les sources d'openBSD.
Le projet OpenCVS est une réécriture, à fonctionnalités équivalentes, de CVS ayant pour objectif d'avoir une solution sécurisée et maintenue par rapport au CVS actuel qui est un peu délaissé.
cf. http://www.opencvs.org/index.html et http://linuxfr.org/~patrick_g/16411.html
La formulation de la déppêche est un peu brute effectivement, mais je pense que la vérité est quelque part au milieu, ou ailleurs...
-
[^]Re: OpenCVS
Posté par patrick_g (page perso, ) le 20/09/2006 à 13:28. (lien). Évalué à 7.>> CVS est largement utilisé et tout le monde ne vas pas passer à subversion
Tout le monde non mais y'a quand même du lourd qui a basculé :
KDE est passé à Subversion.
Gnome est passé à Subversion.
GCC est passé à Subversion.
Python est passé à Subversion.-
[+] [^]Re: OpenCVS
Posté par spotty () le 20/09/2006 à 14:40. (lien). Évalué à -5.Rhooo, y a encore des nazis anti expression libre qui m'ont moinssé, je suis triste de ne pas pouvoir rester dans le rang :-D
Bon, soyons sérieux maintenant, KDE, gnome, GCC... sont des gros projets mais ce ne sont pas tous les projets opensources qui existent.
subversion n'est pas le remplaçant de CVS, certains projets le choisiront, d'autres non, d'autres utiliseront d'autres produits (openCVS, gits...) Arrêtez de dire que subversion est le remplaçant de CVS, ce n'est pas vrai : les concepts, commandes, possibilités et façon d'utiliser dont différents. Les utilisateurs intensif du branch/merge ne trouvent pas encore leur bonheur sous subversion.
Et puis, pourquoi voulez-vous qu'un soft en élimine un autre ?? MS déteint sur vous ou quoi ???
Moinssez moi, c'est si facile et anonyme-
[^]Re: OpenCVS
Posté par Laurent J (page perso, ) le 20/09/2006 à 15:02. (lien). Évalué à 4.>Arrêtez de dire que subversion est le remplaçant de CVS, ce n'est pas vrai : les concepts, commandes, possibilités et façon d'utiliser dont différents.
bah je ne sais pas mais pour moi, ça l'est quand même hein : c'est le même type de gestionnaire de version. Il en reprend la majorité des commandes, mais en plus simple. À la différence que svn est plus performant, les rapports de log, d'history &cie sont beaucoup plus clairs, la doc est vraiment mieux foutu, la numérotation des commits ultrasimple (et pas des numeros à 15 chiffres et points), et svn corrige des lacunes de svn (historisation des renomages/deplacements par ex..) etc..
Quand on a fait du CVS, passer à SVN est du pure bonheur. Il y a juste cette nouvelle "vision" des branches/tags, et la disparition des modules qui peuvent perturber au début, mais personnellement, je m'y suis adapté trés vite.
> pourquoi voulez-vous qu'un soft en élimine un autre ??
parce que c'est ce qui se passe en vrai dans la vrai vie du monde réèl... C'est un constat, pas une affabulation.
-
[^]Re: OpenCVS
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:41. (lien). Évalué à 10.Le but avoué de Subversion est de proposer un remplaçant à CVS. Le projet à été lancé au début de ce siècle, par le groupe qui représentait les derniers mainteneurs actifs du code source de CVS, et qui étaient donc dans une position idéale pour juger des faiblesses de CVS et les corriger. L'un des fondateurs de Subversion, Karl Fogel, a écrit un livre sur l'utilisation de CVS qui est une référence sur le sujet.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.
-
[^]Re: OpenCVS
Posté par Guid (page perso, ) le 20/09/2006 à 20:02. (lien). Évalué à 6.Je veux bien manger me manger une chaussure si tu me montres que la majorité des projets qui utilisent encore CVS le font par choix technique délibéré et pas à cause du coût (en temps) d'une migration.
Subversion c'est CVS, mais en _mieux_ (inutile de lister les améliorations une nième fois, j'espère). Et c'est pour ça qu'il est présenté comme son remplaçant.
-
-
[^]Re: OpenCVS
Posté par Laurent J (page perso, ) le 20/09/2006 à 14:53. (lien). Évalué à 0.et Mozilla est en train d'y reflechir trés sérieusement. ils veulent bazarder CVS_qui_suxor et sont en train de voir un autre soft qui se rapprocherait le plus de leurs besoins : http://wiki.mozilla.org/Version_Control_System_Requirements
Et ils commencent à faire des tests avec subversion :
http://weblogs.mozillazine.org/preed/2006/08/subversive_subv(...)
Et personnellement, tous mes projets persos sont sous subversion. Il y a longtemps que j'ai dit au revoir à CVS (qui suxor, rappelons-le)...-
[^]Re: OpenCVS
Posté par Boa Treize (page perso, ) le 20/09/2006 à 21:17. (lien). Évalué à 3.Et ils font aussi des tests avec Git...
-
-
[^]Re: OpenCVS
Posté par Vivi (page perso, ) le 20/09/2006 à 15:34. (lien). Évalué à 3.Gnome est passé à Subversion
non pas encore, il y a eu des problèmes lors de la migration est c'est repoussé pour l'instant.
-
Merge tracking
L'un des grands sujets du sommet est le support de suivi de branches ("Merge Tracking"), fonctionnalité réclamée depuis longtemps et déjà bien avancée dans la version de développement.
Vous êtes sur de ça ?
Sur la roadmap:
http://subversion.tigris.org/merge-tracking/
Subversion's own merge tracking support is still in the conception stage. Email the development list if you're interested in participating in its definition or implementation.
Et si on se rend sur les specs
http://subversion.tigris.org/merge-tracking/requirements.htm(...)
on se rend compte des limitations actuelles.
- risque de doublons ou d'effacement lors des merges répetés
- pas d'historisation des renommages de répertoires ce qui fait qu'il est impossible de maintenir 2 arborescences qui auraient divergé
- pas d'assistant de merge d'arborescence entière.
Lorsqu'un projet doit faire évoluer son architecture dans le cadre d'une migration technique ou d'un changement au niveau du métier c'est très pénalisant
J'évalue actuellement l'opportunité pour ma boîte de remplacer Clearcase SVN en tant qu'outil de GCL par défaut pour les projets, mais de telles limitations me paraissent rédhibitoire. Son usage en l'état ne pourra être envisagé que pour des petites équipes.
David, toi qui semble suivre les discussions sur le sujet peux-tu nous apporter quelques précisions ou un pointeur.
-
[^]Re: Merge tracking
Posté par Geo Vah () le 20/09/2006 à 12:11. (lien). Évalué à 2.Pour remplacer Clearcase par SVN, ca dépend totalement de comment est utilisé clearcase...
Typiquement, ou je bosses, il n'est utiliséque en vue dynamique et là c'est impossible à le remplacer...-
[^]Re: Merge tracking
Posté par golum () le 20/09/2006 à 12:29. (lien). Évalué à 2.Nous n'envisageons pas de migrer les projets existants mais seulement d'utiliser SVN pour des nouveaux projets j2ee.
L'interêt des vues dynamiques, c'est uniquement pour les dev type C/C++ ou tu peux bénéficier du partage d'objets dérivés et du clearmake (audit de fabrication, detection autmatique des cibles , optimisations parallèles, ...) ou pour les devs cross plateformes ou tu uilses un IDE windows et que tu compiles et teste sous Unix.
Avec les outils de fabrication d'aujourd'hui et les dernières evolutions des compilos c'est de moins en moins interessant.
Pour les autres cas ca n'a guère d'intêret d'autant que les vues dynamiques ont pas mal d'inconvénients par ailleurs.-
[^]Re: Merge tracking
Posté par golum () le 20/09/2006 à 12:36. (lien). Évalué à 2.Ah et il ne faut pas croire tout ce que te disent les marketeux d'IBM.
Déjà ils n'utilisent pas CC (Eclipse et WSAD sont sous CVS, ...) et ca fait longtemps qu'il on perdu les sources du noyau de CC (quand il l'on auto-hosté) et c'est pour ca qu'il ne le font jamais évoluer mais préfèrent faire tout leur buzzword avec la surcouche UCM. Ceux qui se sont dèjà battu avec des fichiers corrompus par des lignes avec des Ctrl M et d'autres sans me comprendront.-
[^]Re: Merge tracking
Posté par Geo Vah () le 20/09/2006 à 13:18. (lien). Évalué à 1.humm UCM ca devient utile dans certain cas précis, ou d'autre préfèrent aussi utiliser des buzzword comme CMMI...
-
[^]Re: Merge tracking
Posté par golum () le 20/09/2006 à 13:34. (lien). Évalué à 2.Bon on va pas rentrer dans les details techniques car il y aurait beaucoup à dire et on risque de digresser pas mal.
UCM Clearcase et ClearQuest outillent le processus UCM qui s'inscrit dans la méthodologie RUP.
Il n'en demeure pas moins que c'est une rustine aux lacunes de Clearcase (c'est grâce à la couche UCM que Clearcase bénéficie de la notion de changeset qui n'existent pas dans noyau. ...). Dans certains cas l'héritage est même pénalisant. Par exemple tu as une branche par développeur (stream developpeur) et pourtant tu es toujours obligé d'extraire tes fichiers avant de le modifier. Quel est l'intêret ? La reservation sert juste à prevenir les autres developpeurs que tu travailles sur le fichier. Là ils ne travaillent pas sur la mme branche ^dons ils s'en moquent un peu.
Si tu veux affecter une activité que tu as démarré (une demande de changement) à quelqu'un d'autres tu es obligé de la rendre mais comme tu as commité tu ne peux pas revenir en arrière sasn faire un merge (un autre outil
te ferait un simple revert de ton workspace). J'en passe et des meilleures
Il n'y a pas besoin d'UCM Clearcase/Clearquest pour faire de l'UCM. C'est juste un processus et je vais peut-être etudier sa transposition avec SVN/Trac si ce n'est déjà fait quelquepart.
-
-
-
-
-
[^]Re: Merge tracking
Posté par David Anderson (page perso, ) le 20/09/2006 à 18:54. (lien). Évalué à 4.Alors, je n'ai pas les détails (je les aurai au SVN Summit), mais ce que je sais, c'est que dans le dépot officiel du projet, il y a une branche merge-tracking, et que ceux qui travaillent dessus disent être suffisament avancés dans leur travail pour que la branche soit utilisable, au moins par les développeurs. Il y a encore tout un travail de stabilisation et de tests avant de pouvoir diffuser ca au monde.
Concernant le remplacement de Clearcase par Subversion, je dois être franc et te dire que ça va être difficile. Clearcase est plus, bien bien plus, qu'un simple outil de revision control. Il incorpore toute une floppée d'autres aspects du cycle de développement. De plus, son UI est très différente de tous les autres outils existants, ce qui va rendre la migration vers autre chose difficile.
Donc, je serais de l'avis de commencer, comme tu le suggères, par des petites équipes pilotes. Etudiez les problèmes de migration qu'il y a sur un petit projet, pour mieux planifier une éventuelle migration totale.
À noter également que Collabnet, l'entreprise qui est à l'origine de Subversion, propose des solutions plus complètes se basant sur Subversion, qui pourraient éventuellement remplacer plus efficacement l'intégralité de Clearcase. Disclaimer: Je ne suis pas employé de Collabnet, je n'ai jamais déployé leurs systèmes en entreprise. J'en ai simplement entendu du bien, et il est clair qu'ils rassemblent encore à ce jour une grande expertise sur Subversion, qu'aucune autre entreprise ne peut à ce jour prétendre égaler.
Si tu as besoin d'aide pour la migration, n'oublie pas la liste de diffusion users@subversion.tigris.org, ou tu trouveras peut-être d'autres gens qui ont fait des migrations depuis Clearcase. Et dans tous les cas, que ce soit un succès ou non, n'oublie pas de nous rapporter le résultat de cette étude/migration, ça nous intéresse!-
[^]Re: Merge tracking
Posté par golum () le 20/09/2006 à 20:21. (lien). Évalué à 2.Merci d'avoir pris la peine de répondre à chacun d'entre nous
Alors, je n'ai pas les détails (je les aurai au SVN Summit),
J'espère que tu nous feras un petit débriefing dans une dépêche.
Pour le reste je suis d'accord avec toi en partie mais je connais assez le domaine pour te dire que CC en tant qu'outil de gestion de configuration (GCL ou SCM) [1] est dépassé. En plus, l'appellation "outil SCM" varie beaucoup d'un éditeur à l'autre. CC seul ne propose pas la gestion des changements qui fait partie de la GCL car il n'offre même pas la notion de changeset. De même la gestion des release en fonction des plateformes n'entre pas dans son périmètre (cf. SpectrumSCM) ou encore celle du déploiement (Endevor)
En combinant diverses solutions open source et tu peux arriver à un resulat équivalent voire meilleur pour bien moins cher (le service ne coutera jamais aussi cher que le cumul du prix des licences et du support)
En tant qu'outil de contrôle de version (il apparait comme ca sur wikipédia [2]) CC offre plein de fonctionnalités que SVN ne propose pas (merge tracking, gestion des composants avec UCM, triggers coté client sur nb d'opérations, vues dynamiques, multisite, algorthmes de stockage de comparaison et de merge par type de fichiers, ...)
Mais avec l'evolution des technologies elles sont de moins utiles et l'architecture du produit devient un vrai handicap et les plus essentielles sont sur la roadmap SVN.
[1] http://en.wikipedia.org/wiki/Software_configuration_manageme(...)
[2]
http://en.wikipedia.org/wiki/List_of_revision_control_softwa(...)
-
Outil de diff/merge
Je profite de cet article pour poser une petite question. Quel est votre outil de diff/merge favori?
Personnellement, j'utilise kdiff3, mais j'ai un peu de mal avec l'édition manuel des conflits. ( J'ai auparavant eu à travailler surtout avec le merge de ClearCase et BeyondCompare, et depuis je peine à trouver qqch d'aussi bien )
-
[^]Re: Outil de diff/merge
Posté par Philippe Fremy (page perso, ) le 21/09/2006 à 11:46. (lien). Évalué à 4.winmerge
Bon, ca marche que sous windows, mais c'est opensource :-)
-
[^]Re: Outil de diff/merge
Posté par Matthieu Moy (page perso, ) le 23/09/2006 à 12:53. (lien). Évalué à 1.Emacs (Ediff, smerge-mode en particulier)
Enfin !!
Le moteur de diff interne à Subversion peut maintenant ignorer les différences en nombres d'espaces/tabulations et en formats de fin de ligne, pour des diffs qui vont à l'essentiel de ce qui a véritablement changé
Enfin, on va pouvoir avoir des diffs lisibles. j'en peux plus de recevoir des messages de commits contenant des diffs constitués pour 95% de changements d'indentation, tout ca à cause d'éditeurs différents/mal configurés/style d'indentation non communs.
La guerre sur les styles d'indentation par défaut de vim/emacs va peut-être prendre fin. Si seulement tout le monde pouvait utiliser indent, et se mettre d'accord sur un style commun...
-
[^]Re: Enfin !!
Posté par Laurent Pointal (page perso, ) le 20/09/2006 à 13:29. (lien). Évalué à 5.Il "peut"... j'espère que c'est réglable. Parce qu'avec des sources Python, les espaces sont plutôt importants.
-
[^]Re: Enfin !!
-
-
[^]Re: Enfin !!
Posté par oliv () le 20/09/2006 à 14:12. (lien). Évalué à 3.M'enfin, toute personne utilisant des espaces pour l'indentation devrait être stérilisée, pendue, découpée en petits cubes, cubes subséquemment incinérés dans une torche à plasma. Mais vu le succès de Python, ça va demander pas mal de boulot de mettre mon plan en application.... un projet à long terme par conséquent. Je commencerai donc par me concentrer sur les hérétiques qui utilisent l'indentation comme objet de syntaxe, renouvelant l'erreur (mélange du fond et de la forme) qui a pollué le HTML et les traitements de texte pendant 10 ans. À noter que les deux catégories se superposent assez bien, ce qui fera moins de boulot pour la deuxième phase du projet (la vasectomie prend du temps sur un sujet non consentant).
-
[^]Re: Enfin !!
Posté par Laurent Pointal (page perso, ) le 20/09/2006 à 14:53. (lien). Évalué à 2.mélange du fond et de la forme
Bonne forme + bon fond = que du bonheur.
-
[^]Re: Enfin !!
Posté par rewind () le 20/09/2006 à 15:45. (lien). Évalué à 5.Généralement, ceux qui utilisent des tabs pour indenter les utilisent aussi pour aligner les commentaires en fin de ligne... Et c'est là que les ennuis commencent parce que, autant le début de ligne ne pose pas de problème, autant la fin de ligne est problématique quand on n'a pas la même taille de tabulation. Donc puisqu'il faut utiliser les espaces pour la fin de ligne, autant les utiliser aussi pour le début de ligne, quitte à perturber certains personnes qui préfèreront 3 espaces plutôt que 2 ou 4.
-
[+] [^]Re: Enfin !!
Posté par arnaudus () le 20/09/2006 à 16:32. (lien). Évalué à -3.L'indentation et l'alignement dans les fichiers source sont une hérésie qui persiste encore de nos jours pour des raisons historiques. Ça aurait toujours dû être le boulot de l'éditeur de rajouter les espaces et les sauts de ligne là où il faut, le fichier source devant contenir le code à la queue leu leu pour 1) gagner de la place et 2) forcer l'utilisateur à utiliser un éditeur qui sache gérer le code :-)
Évidemment, la tâche n'est pas simplifiée par les langages à la con qui accordent un sens à des caractères invisibles (ou pire: à la répétition de caractères invisibles, comme les doubles sauts de ligne en Latex). Je pense qu'on devrait retrouver les types qui ont mis au point ces langages, leur couper les couilles, les faire frire et leur faire bouffer.
Sans déconner, est-ce que vous pourriez estimer la perte de productivité de l'humanité toute entière due aux milliards d'heures perdues par des devs à réaligner du code, à discuter sans fin de conventions de codage ou à débogguer un Makefile dans lequel un esprit de l'axe du Mal(TM) a remplacé une tab par des espaces?-
[^]Re: Enfin !!
Posté par Sytoka Modon (page perso, ) le 20/09/2006 à 21:06. (lien). Évalué à 3.Tu mélanges deux choses dans ton post : l'indentation et l'alignement puis dans une seconde partie, les fins de lignes.
A ma connaissance, quasiment tout le monde trouve très bien les fins de lignes. D'ailleurs, le C++ a bien rajouté // pour faire des commentaires (jusqu'a la fin de ligne) car les commentaires du C n'était pas idéal dans plein de cas (pas pour rien que presque tous les langages ont un(deux) caractères qui marque les début des commentaires : # pour les langages de scripts, -- en ada, ; fichier de conf DNS...
Ensuite, dans les langages impératifs, le saut de ligne marque en général le passage à l'instruction suivante, c'est tout à fait naturel.
Par ailleurs, je ne partage pas du tout ta critique de LaTeX du double saut de ligne pour changer de paragraphe. C'est encore une fois tout à fait naturel et particulièrement facile à relire (bien plus que le </p> !)
Par contre, les tabulations sont une plaie, surtout dans les fichiers de conf (makefile, rsnapshot). Je ne comprends pas pourquoi les deux caractères '->' en début de ligne dans un Makefile ne soit pas équivalent à la tabulation. On aurait ainsi une évolution en douceur et compatible des Makefiles vers quelque chose de bien plus maintenable sur le long terme.
En conclusion, j'aime bien que le source soit sous un format basique que je puisse imprimer facilement. Je n'ai pas envie d'être obliger d'avoir un éditeur particulier pour avoir une mise en page lisible. Avec un tel système, on finirait par avoir un éditeur par langage ! Il ne faut pas lier un langage de programmation avec l'éditeur ou le système sera trop contraint pour évoluer. Je le vois bien avec les Windowsiens qui arrivent sous linux et sont perdus car ils n'ont pas leur VisualStudio. Que diable, ils peuvent bien éditer avec l'éditeur qu'ils préfèrent et lancer "make" dans le shell à coté. Une fois qu'ils ont compris cela, ils commencent à saisir un petit peu la souplesse d'une machine de type UNIX.-
[^]Re: Enfin !!
Posté par arnaudus () le 21/09/2006 à 08:40. (lien). Évalué à 3.Bon, j'y ai peut-être été un peu fort sur les sauts de ligne, mais je reste quand même persuadé que le saut de ligne est un caractère "forme" et pas "fond", tout comme l'espace et la tabulation.
Utiliser un éditeur de texte qui ne sait pas lire le code, par exemple Word, pour lire un fichier C, ne rendrait pas le truc illisible :
int main(int argc,char** argv){printf("Hello Word!\n");}
reste quelque chose de "compréhensible" (bon, c'est sûr, si le fichier fait 200ko, ça va être moins lisible...). Mais ça reste du texte, et ça ne compromet en rien la lecture, la modification, la recherche de chaines de caractères etc. Mais la mise en page est neutre, et c'est à l'éditeur de texte, si l'utilisateur le veut, de remettre ça en page pour faciliter la lecture et l'édition. Donc je persiste à dire par exemple qu'en C, le saut de ligne est un caractère de mise en forme, il n'a aucun sens (autre que celui de séparateur, et malheureusement, de fin de commentaire pour les // du C++). Au passage, cette "suppression de tous les caractères inutiles avant publication" est courante pour le HTML, je ne vois pas pourquoi ça ne pourrait pas se faire pour les autres languages.
L'informatique n'échappe pas à la tendance naturelle à l'immobilisme : si un gars s'est fait chier 20 ans avec les Makefile merdiques, il va voir d'un mauvais oeil l'apparition d'une nouvelle syntaxe qui va tout révolutionner.-
[^]Re: Enfin !!
Posté par rewind () le 21/09/2006 à 11:49. (lien). Évalué à 4.Error: helloworld.c:1
et là tu as l'air très bête si tu as tout sur la même ligne...
Pour un compilateur, certes, les sauts de ligne ne veulent rien dire (et encore, cpp geulent s'il n'a pas son fin de ligne à la fin du fichier). Mais nous sommes des humains, et nous utilisons des outils simples qui permettent d'afficher des sauts de lignes alors on en profite.-
[^]Re: Enfin !!
Posté par arnaudus () le 21/09/2006 à 20:37. (lien). Évalué à 5.Les langages de programmation (enfin les "vieux") ont été conçus à une époque où on n'avait pas de recul sur les gestions de versions, sur les éditeurs de texte, sur la diversité des conventions, etc. Ils trainent donc des erreurs du passé, et le mélange fond/forme dans un fichier source, c'est AMHA une erreur de conception profonde du langage. Les sauts de ligne faisant partie de la forme (et malheureusement parfois du fond), ils sont traînés comme des boulets depuis 20 ans.
Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.
Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).
Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.
-
-
-
-
[^]Re: Enfin !!
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 20/09/2006 à 21:23. (lien). Évalué à 5.Tu utilise quoi comme éditeur LaTeX ? hexdump ? Parce que dans la plupart des éditeurs courants, deux sauts de lignes de suite, ce n'est pas "invisible". Enfin, personnellement, les sauts de ligne, je n'ai pas l'impression que ce soit des caractères invisibles?
--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
-
-
-
-
[^]Re: Enfin !!
Posté par David Anderson (page perso, ) le 20/09/2006 à 19:00. (lien). Évalué à 1.Version détaillée, puisque ça semble intéresser une bonne portion de gens:
` svn diff -x '-w' ` produira un diff unifié qui ignore les changements d'indentation. Il me semble qu'il est possible de configurer son client de telle manière qu'il passe systématiquement le -w au moteur de diff interne. Par défaut, le diff est toujours un diff unifié normal, qui montre tous les changements.
A noter que la nouveauté ici est bien que le moteur de diff *interne* de Subversion supporte ces options. Il était déjà possible de dire a `svn diff` d'utiliser un logiciel de diff externe, comme GNU Diff, et lui passer des options similaires.
Problème des Mac
Rien à voir, quoique...
Je me suis amusé à faire un partage WebDav avec autoversionning subversion. C'est la meilleure méthode que j'ai trouvé pour faire du WebDav avec une gestion, modeste, des droits sur les fichiers (Je dis modeste car il y a quasiment toutes les briques pour faire avec svn la grande mode actuelle : les bureaux virtuels. Mais pour en arrivé là, il faut que le client puisse gérer les droits).
Les utilisateurs montent cela sur leur postes, Windows, Mac, Linux. Et là, le problème des Mac avec la pollution des dossiers que ces bestioles génèrent...
D'où ma question : est-il prévu dans svn d'avoir des hooks tout près à l'emploi qui élimine dès le commit ces fameux, et pour le moins épouvantable, fichier spécifique au Mac ? En effet, je ne dois pas être le seul qui a un repository complètement pollué par ces fichiers.
-
[^]Re: Problème des Mac
Posté par Oook () le 22/09/2006 à 00:00. (lien). Évalué à 2.Y'a ça (sur les client pour ce que j'ai compris)
http://docs.info.apple.com/article.html?artnum=301711
Sinon Xcode utilise svn de base, je pense qu'il doit y avoir des outils installables. Je sais que ça existe pour les clés : vu comment OS X traite les montages, ça peut peu-être se transposer...-
[^]Re: Problème des Mac
Posté par Sytoka Modon (page perso, ) le 22/09/2006 à 05:24. (lien). Évalué à 2.Je connaissais mais je n'ai pas testé. D'abord, apple est très positif sur la technique qu'il propose (votre finder peut planter n'importe quand !). Ensuite, il n'y a pas que le fichier .DS_STORE mais il y a un fichier ._*** pour chaque fichier du dossier et pour ceux-là, je n'ai rien vu.
Mon unique idée serait donc de mettre en place un hook dans subversion qui analyse la tansaction et vire une partie des fichiers de cette transaction.
Bref, c'est Apple quoi ;-(
-
SVN, HTTP et dossier
Il y a une fonctionalité super avec svn, c'est le HTTP (ou HTTPS). Un dépot et tu explore la dernière version de ton dépot avec un simple navigateur sur l'url du dépot. Un petit xsl te transforme le XML du serveur en html tout bien jolie.
Question : pourquoi le XML que le serveur SVN génère a si peu d'information. On a le droit d'avoir en double le nom du fichier, donc une fois de trop, mais pas le poids (taille) du fichier, la personne qui a réalisé la dernière révision, ni la date de modification.... Bref, pas mal d'information accessible facilement en ligne de commande.
Avec ce type d'information, en modifiant un peu le filtre xsl fourni, on pourrait avoir un affichage avec un navigateur du même type que celui que donne Apache d'un dossier. L'utilisateur lambda ne verrait même pas qu'il a affaire à un gestionnaire de version.
C'est aussi cela qui me plait avec SVN, c'est qu'il arrive à se faire oublier et que l'on peut avoir l'impression de travailler sur des dossiers comme les autres.
Dans le même ordre d'idée, un module fuse : "svnfs", me paraît complètement indispensable ;-)
bazaar
Bon, je sais, le sujet c'est svn, mais j'aimerais justement parler de mon expérience avec ce système.
A un moment, j'ai décidé d'utiliser un système de gestion de révision pour mes projets personnels. Ces projets sont au stade pré-alpha, des choses complètement instables, et surtout beaucoup de projets morts nés.
La gestion de révision m'intéressait surtout car je devais souvent créer des dossier old1, old2 ... conrtenant des anciennes versions de mes sources que je ne voulais pas jeter mais pas non plus garder car je les avaient remplacées par du meilleur code. J'installe alors SVN.
C'était mon premier contact avec un système de gestion de révisions mais jai eu beaucoup de mal, surtout à faire la différence entre le repository et la copie locale. Je ne comprenais pas (et je ne comprend toujours pas) pourquoi les deux choses doivent être séparées.
Depuis, j'ai découvert bazaar-ng et je trouve ca beaucoup mieux car c'est décentralisé (plein d'avantages il paraît) et surtout car je n'ai pas a créer un repository à part. Je peux déplacer mes dossiers de projets sur une autre partition (lorsqu je n'ai plus de place) ... je suis libre.
Je ne nie pas que svn puisse être très utile, surtout pour des projets organisés, mais dans mon coin, c'était très compliqué de gérer tout ça, alors je préfère bzr que je maîtrise beaucoup mieux. je sais où sont mes fichiers et c'est ça qui est important pour moi.
-
[^]Re: bazaar
Posté par Laurent Pointal (page perso, ) le 21/09/2006 à 11:02. (lien). Évalué à 2.C'était mon premier contact avec un système de gestion de révisions mais jai eu beaucoup de mal, surtout à faire la différence entre le repository et la copie locale. Je ne comprenais pas (et je ne comprend toujours pas) pourquoi les deux choses doivent être séparées.
Même en travaillant seul, tu peux avoir à faire plusieurs copies de travail locales. Le repository sert de point commun à ces différentes copies - tu peux très bien supprimer (rm -rf) une copie locale, ça n'aura aucune incidence sur le repository.
-
[^]Re: bazaar
Posté par golum () le 21/09/2006 à 11:09. (lien). Évalué à 2.Et puis un jour tu vas arrêter de travailler seul dans ton coin et tu va decider de participer à un projet qui concernent plusieurs developpeurs et là, tu va devoir comprendre comment ca fonctionne:
Avec un DVCS (Distributed Version Control System) lorsque je veux récupérer les dernières modif je dois déjà savoir où elle se trouvent (qui détient ce correctif) puis je dois rapatrier ces modifs dans mon repository et puis encore les merger. Que d'étapes
Ensuite je veux envoyer mes modifs et les mêm questions se posent:
A qui les envoyer ?
Dois-je les pusher ou viendra t'on les récupérer chez moi ?
Si je merge les modif de mon voisin chez moi et que lui recupère mes modifs aussi et les merge de son coté on risque de faire le travail en doublon.
Et là les réponse dépendent des outils (head avec monotone) et de l'organisation (un seul intégrateur), des procédures du projet.
Ce qui est révolutionnaire et simplissime quand on est seul devient complexe.
...
Avec un outil centralisé, j'ai une copie à jour du référentiel central, je mets à jour ma copie je travaille, je résoud les conflits et j'envoie.
En outre je ne stocke pas l'ensemble du réferentiel sur mon poste.
Donc effectivement les DVCS ont plein d'avantages lorsque l'équipe est matûre en terme d'organisation mais la contrepartie de leur puissance c'est leur complexité.
Dans un projet collaboratif le gap est encore plus important que pour un outil centralisé. Et les developpeurs sont tellement sensibilés à la gestion de conf dans les écoles qu'il vaut mieux aller au plus simple.-
[^]Re: bazaar
Posté par Joël SCHAAL () le 21/09/2006 à 11:49. (lien). Évalué à 1.Moi je voyais plutôt sa réaction comme 'Pourquoi garder une copie en local ?'.
Après tout, on pourrait aussi bien faire un montage "svn" comme on ferait un montage nfs, sauf qu'on rajouterait des commandes permettant de gérer les commit/update/branch...
Ou alors un modèle plus proche de la base de données : utiliser des transactions pour faire des modifications.
Bon je pense que ces aspects ont déjà été étudiés et qu'en terme d'efficacité ils ne sont pas envisageables. (Ce ne sont que des idées, je ne suis pas allé vérifier...)
-
[^]Re: bazaar
Posté par Boa Treize (page perso, ) le 21/09/2006 à 12:07. (lien). Évalué à 1.Avec un outil centralisé, j'ai une copie à jour du référentiel central, je mets à jour ma copie je travaille, je résoud les conflits et j'envoie.
[caricature]Commence par demander bien bas aux gestionnaire du projet de t'accorder l'immense privilège de pouvoir, avec prudence et respect, apporter une correction infime dans un sous-répertoire (mais pas ailleurs) de leur chef d'oeuvre.[/caricature]
En outre je ne stocke pas l'ensemble du réferentiel sur mon poste.
[caricature]Et quand le serveur crashe, tu perds tout.[/caricature]
Bref, deux avantages du distribué à ce niveau :
- C'est plus égalitaire, pas de verrouillage possible par une quelconque cabbale
- Tout le monde à une copie de l'historique sur son poste (avec des backups en plus, bien sûr)
Par ailleurs, bonne chance pour faire un checkout ou un commit dans le train ou l'avion.-
[^]Re: bazaar
Posté par Sytoka Modon (page perso, ) le 21/09/2006 à 14:09. (lien). Évalué à 2.Je n'ai pas testé (je ne vais pas tardé) mais svk répond à ce point là. Si j'ai bien compris, avec svk et svn, tu as en gros le meilleur des deux mondes, si cela a un sens ;-)
-
[^]Re: bazaar
Posté par golum () le 21/09/2006 à 14:33. (lien). Évalué à 5.Je pense simplement que l'usage n'est pas le même.
Dans le cadre de développement purement communautaire les outils distribués sont plus adaptés. Linux en est le meilleur exemple. Lorsque le développement est conduit en entreprise ou dépend d'une organisation (type Eclipse, Apche, ....) (et non pas d'un homme) le centralisé convient mieux. En entreprise d'autant plus qu'il faut la plupart du temps former les prestataires aux outils de l'entreprise.
[caricature]Commence par demander bien bas à l'intgrateur du projet d'accepter de merger tes modifs mêm mineures dans l'archive de référence[/caricature]
[caricature]Et quand mon dd crashe et que j'ai pas fais de push depui 6 mois je perd tout [/caricature]
D'autant que les solutions de sauvegardes ne sont pas faites pour les chiens , elles s'applique au distribué comme au centralisé
C'est plus égalitaire, pas de verrouillage possible par une quelconque cabbale
Si l'intégrateur refuse de prendre en compte tes patche le pb est le même et il n'est pas plus difficie de forker un repository que de déclarer que son archive est la nouvelle référence.
Tout le monde à une copie de l'historique sur son poste (avec des backups en plus, bien sûr)
Mais personne n'a l'archive de toutes les versions du projet lorsqu'il est très volumineux. Dans ce cas tu es bien obligé de prévoir un serveur pour l'héberger au moins par sécurité et tu te retrouves avec les mêmes contraintes que le centralisé
Par ailleurs, bonne chance pour faire un checkout ou un commit dans le train ou l'avion.
Ton checkout/commit se fait dans l'archive local ,ca ne signifie pas que tu mettes à disposition du reste du monde.
Dans les 2 cas tu peux toujours travailler en déconnecté et tu mets à disposition quand tu reviens sur le réseau (commit en centralisé et push/pull en distribué).
Le seul avantage est qu tu peux "sauvegarder" des versions intermédiares de ton travail mais le travail de fusion reste entier.Comme avantage c'est bien maigre comparé aux contraintes d'organisation.
Que se passe t'il quand l'intégrateur est overbooké par un afflux de patch. Le projets doit s'organiser en sous-branche afin d'absorber la charge.
Dans le cas d'un modèles centralisé plusieurs intégrateurs peuvent travailler de concert
Encore une fois l'usage dépend du besoin et je ne pense pas qu'on puisse dire que l'un est meilleur que l'autre.
-
-
-
[^]Re: bazaar
Posté par wilk (Jabber id, page perso, ) le 22/09/2006 à 07:59. (lien). Évalué à 4.J'ai l'impression que ça n'a pas été dit. Maintenant bazaar peut aussi être utilise en centralisé comme svn ou cvs, il y a d'ailleur pas mal de tutos à ce sujet sur leur site. Ca permet de passer en douceur du centralisé au décentralisé ou de mélanger les deux.
On peut également au choix garder le repository dans le dossier du projet (.bzr) ou dans un repository extérieur, local ou distant, avec un système de mise à jour très pratique si on a beaucoup de branches (pour ne pas tout dupliquer) ou en guise de sauvegarde.
Ainsi toutes les combinaisons sont possibles ! Par exemple pour un même projet quelques devs peuvent travailler en centralisé comme cvs/svn pendant que d'autres travaillent sur leurs branches hors ligne.
On omet souvent de dire aussi que c'est très pratique même si on travaille seul où on ne cré pas des branches par développeur mais des branches par clients ou pour ajouter une fonctionalité, corriger un bug etc.
Le seul problème je trouve c'est qu'il y a tant de combinaisons possibles et de modes d'organisation, que ça devient un poil difficile de savoir laquelle sera la meilleure.
Presque off topic
Sans rechercher le troll, je me demande ce qui se passe chez Gnu Arch, savannah avait parlé d'y passer.
Des commentaires sur Gnu Arch vs autre ? Quelques aspects qui m'intéressent chez Gnu Arch c'est non seulement le branch/merge efficace mais aussi la décentralisation et la signature des changements.
Tout info est bienvenue
-
[^]Re: Presque off topic
Posté par golum () le 22/09/2006 à 09:27. (lien). Évalué à 4.Je pense que tu trouveras ta réponse ici:
http://linuxfr.org/~GomGom/19107.html-
[^]Re: Presque off topic
Posté par Boa Treize (page perso, ) le 23/09/2006 à 10:26. (lien). Évalué à 2.Ce journal a plus d'un an !
Une version de GNU Arch est sortie cet été, et Tom Lord est tout à fait présent sur les mailing-lists de GNU Arch, même si ce n'est peut-être plus lui qui maintient le projet.
Par contre, la plupart des utilisateurs semble être partie vers d'autres horizons. (Git, Mercurial, Bazaar, principalement, je suppose.)
-
Cette page a été générée par Templeet en 0.2651s (dont 0.0329 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.