samedi 11 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[30] Vers un logiciel de statistiques facile à utiliser pour KDE
[14] GCompris sort en version 7.4
[77] Sortie de Glest 2.0
[66] Sortie de Linux Terminal Server Project 4.2
[42] Sortie de KOffice 1.5
[2] Tinyquizz 2.3 est sorti
[12] PyKota v1.24 est sorti !
[7] Kde Image Menu 0.9.0
[2] Sortie de Nuface 1.0
[83] EiffelStudio devient un logiciel libre

Liens connexes

L'annonce (742 hits)
Téléchargement (348 hits)
Documentation de GIT (701 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Logiciel : Sortie de Git 1.3.0

Posté par Louis Nyffenegger (page perso, ). Modéré le 23 avril 2006.

Junio Hamano, mainteneur officiel du projet, a annoncé une nouvelle version du logiciel Git sur la liste de discussion du projet

Git est un système de gestion de code source utilisé par les développeurs du noyau Linux, entre autres. Le logiciel a été développé initialement par Linus Torvalds pour remplacer Bitkeeper devenu payant (arrêt de la distribution d'une version gratuite pour être précis).

Cette nouvelle version amène de nombreux changement, décrits dans la suite de l'article.

L'annonce (742 hits)
Téléchargement (348 hits)
Documentation de GIT (701 hits)

> Lire la suite (22 commentaires, moyenne: 3,4). [dépêche : 735 caractères]

Les changements:

tout d'abord, la création de git-cvsserver qui permet d'accéder à un serveur git à partir d'un client CVS classique ;
la gestion des fichiers diff est maintenant complètement intégrée dans git (plus d'appel à la version GNU de diff) ;
les dates sont maintenant en notation européenne.

3 projets périphériques sont maintenant intégrés dans git :

une interface alternative à svn ;
2 interfaces pour emacs ;
un système pour visionner le code source facilement.

On peut d'ailleurs noter le nombre important de contributeurs dans le changelog, signe révélateur de la bonne santé du projet.

Pour finir, un grand nombre de bug a été corrigé.

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.

Bugs

Posté par Boa Treize (page perso, ) le 23/04/2006 à 19:34. (lien). Évalué à 10.

Précisons quand même, au niveau du « grand nombre de bugs », qu'il s'agit pour bonne partie de bugs introduits lors du développement de nouvelles fonctionnalités, de bugs mineurs ou de cas très particuliers. Je ne crois pas que Git se soit trimballé de gros bugs sérieux pendant longtemps ou dans une de ses versions stables.

(Et puis Git facilite la création d'énormes ChangeLogs exhaustifs, là où avant on avait seulement les points et les bugs les plus marquants.)

Git, en un an, est devenu un gestionnaire de source puissant et très performant, ses fonctionnalités de base sont maintenant bien stabilisées. Je vous invite à le découvrir.

Ceci dit, Git pêche encore sur quelques points : il lui manque un port natif sous Windows (il marche bien sous Cygwin) et une internationalisation, notamment.

Quelques liens vers des points intéressants de la documentation :

Git au quotidien, en une vingtaine de commandes
http://www.kernel.org/pub/software/scm/git/docs/everyday.htm(...)

Le glossaire (Git a quelques termes spécifiques)
http://www.kernel.org/pub/software/scm/git/docs/glossary.htm(...)

[^]Re: Bugs

Posté par Pinaraf (Jabber id, ) le 24/04/2006 à 11:29. (lien). Évalué à 4.
D'ailleurs, Git est utilisé par les devs de X.org aussi...

Petite faute

Posté par Bob Billy () le 24/04/2006 à 07:24. (lien). Évalué à 0.

la gestion des fichiers diff est maintenant complètement intégré dans git (plus d'appel à la version GNU de diff) -> la gestion des fichiers diff est maintenant complètement intégrée dans git (plus d'appel à la version GNU de diff) ;

Date

Posté par outs () le 24/04/2006 à 09:37. (lien). Évalué à 2.

C'est quoi la notation européenne des dates ?

Je connais la notation internationale (2006-04-24), mais européenne je vois pas. Sous google j'ai surtout trouvé des références à l'heure sur 24h plutot que d'utiliser am/pm.

[^]Re: Date

Posté par Benoît Sibaud (Jabber id, page perso, ) le 24/04/2006 à 12:00. (lien). Évalué à 5.
Voir par exemple
http://www.linux-france.org/article/serveur/psql/Postgres-7.(...)

« ISO

Utilise les dates et heures de style ISO 8601 (YYYY-MM-DD HH:MM:SS). Utilisé par défaut.
(...)
European

Utilise dd/mm/yyyy pour les représentations numériques des dates.

NonEuropean, US

Utilise mm/dd/yyyy pour les représentations numériques des dates.
»
- [^]Re: Date
  
  Posté par Boa Treize (page perso, ) le 24/04/2006 à 16:04. (lien). Évalué à 3.
  Je crois pas qu'il y ait de standard européen : chaque pays a sa combinaison jour-mois-années, avec son séparateur fétiche. Le standard ISO est venu proposer un terme à ces incompatibilités.

Mercurial, le fils caché de GIT grandit lui aussi

Posté par Edouard Gomez (page perso, ) le 24/04/2006 à 10:19. (lien). Évalué à 9.

Excusez mon titre foireux, c'est lundi :-)

Je voulais profiter de cette news sur GIT pour parler de son cousin Mercurial. Pour ceux qui ne connaissent pas, Mercurial est né suite à la publication un peu hative de GIT par Linus Torvalds. Matt Mackal trouvait que GIT utilisait des raccourcis techniques un peu gros et décida de coder un prototype de SCM en python pour tenter de faire quelque chose de plus propre. Voilà coté historique. Dans la pratique les deux s'utilisent globalement de la même façon. Mercurial possède un meilleur support windows que son homologue.

Donc Mercurial 0.8.1 est sorti il y a de çà 2 semaines en apportant un lot assez important de fonctionnalités.
Nouvelles extensions:
- mq: gestion de queue de patchs. S'inspire du workflow d'un quilt, mais on garde les avantages d'avoir ses sources sous contrôle d'un SCM
- mail: où l'art d'envoyer ses changements via email sans se soucier de rien.
- gpg: permet de signer chaque changeset pour les gens qui commit, et de façon symmétrique, de vérifier les signatures pour ceux qui pull les changesets.
- hgbisect: extension qui aide a retrouver le changeset coupable d'un bug identifié sur un intervalle de révisions donné.

Nouvelles fonctionnalités:
- La sortie de plusieurs commandes (dont 'log') peut être patronnée (templatée), de la même façon que les pages web de la commande serve. On peut donc par exemple générer des ChangeLog dans un format propre à son projet.
- Possibilité d'utiliser la commande 'incoming' sur des repositories distants et ainsi savoir quels changements seraient rapatriés en local.
...

Bugfix:
- Quelques bugs sous windows, principalement des différences de comportement de python sous les environnements Unix et Windows.
- ... hg log pour les courageux :-)

Et le développement continue... la future version intègre déjà un nouveau format de repository qui peut alléger leur taille jusqu'à 40%, en utilisant deux fois moins d'inodes... ce changement a pour effet de minimiser la mémoire requise à pas mal d'endroits, d'accélerer certaines commandes... bref que du bon. Une commande 'archive' est arrivée pour faire des export des sources très simplement en zip, targz, tarbz2...

Enfin je veux pas trop vampiriser la news sur GIT pour promouvoir Mercurial, mais que tous ceux qui souhaitent utiliser GIT, testent aussi Mercurial. Mercurial est souvent plus "propre" que GIT, de plus il est portable... user friendly et son poil brille plus fort que celui de GIT :-)

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

Posté par ribwund () le 24/04/2006 à 10:46. (lien). Évalué à 1.
Notons aussi que Mercurial va devenir le SCM distribué pour le developement de OpenSolaris après une review de Bazaar-NG, Git et Mercurial:
http://mail.opensolaris.org/pipermail/tools-discuss/2006-Apr(...)

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

Posté par Boa Treize (page perso, ) le 24/04/2006 à 16:19. (lien). Évalué à 6.
Soyons honnêtes et clairs :

* StGit propose une gestion de queue de patch depuis longtemps
* La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
* Bisect provient directement de Git, c'est une belle et vraie invention de Linus

Bref, les nouveautés de Mercurial sont surtout du rattrappage de retard. Ce qui n'enlève rien à leur mérite, mais on a tendance à confondre nouveauté et innovation, surtout quand il s'agit de fonctionnalités peu familières.

Ceci dit, continuons à être honnêtes :

* Mercurial est très sympa a utiliser sous Windows
* Mercurial a effectivement le poil plus brillant
* Mercurial est plus avancé d'un point de vue internationalisation (l'infrastructure est là, reste à traduire)

Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).

Niveau projets connus, MoinMoin est passé ce week-end d'Arch à Mercurial, de préférence à Git, ce qui est purement logique (tous deux écrits en Python, et le wiki de Mercurial, c'est MoinMoin -- affinités fortes).

Du côté de Git, outre X.org déjà mentionné, il y a également Wine, qui a un des sources codes les plus bourrins que je connaisse (la compilation nécessite plus d'un giga d'espace disque). Bref, Git intéresse les gros projets.
- [^]Re: Mercurial, le fils caché de GIT grandit lui aussi
  
  Posté par Pinaraf (Jabber id, ) le 24/04/2006 à 20:07. (lien). Évalué à 4.
  il y a également Wine, qui a un des sources codes les plus bourrins que je connaisse (la compilation nécessite plus d'un giga d'espace disque)
  Et OpenOffice reste avec son CVS... (plus de 5Go d'espace disque pour compiler, wine fait petit joueur à côté)
- [^]Re: Mercurial, le fils caché de GIT grandit lui aussi
  
  Posté par Edouard Gomez (page perso, ) le 24/04/2006 à 20:40. (lien). Évalué à 5.
  Cette réponse n'a rien de trollesque... si ton post visait à préciser que toutes ces fonctionnalitées étaient présentes dans GIT, il est vrai que j'aurais pu le mentionner dans la mesure où je suis l'évolution des deux projets sur leurs MLs respectives.
  
  Donc je te reprend sur les quelques points pour apporter des précisions:
  
  >StGit propose une gestion de queue de patch depuis longtemps
  
  La gestion n'est pas totalement identique. Mais la palme de la gestion de patchs revient dans ce cas à Quilt de Andrew Morton dont StGit et Mq sont des copies fonctionnelles qui profitent des couches SCM fournies par Git et Mercurial.
  
  >La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
  
  Tout à fait vrai. Linus a toujours aimé avoir des outils de gestion de patchs au format mbox (format historique des emails sous unix). Il est donc tout à fait normal qu'il l'ait implémenté dès le départ dans GIT...
  
  >Bisect provient directement de Git, c'est une belle et vraie invention de Linus
  
  Cette fonctionnalité vise surtout à formaliser par du code une pratique très couramment utilisée par tous ceux qui recherchent les bugs dans le noyau. L'algorithme est une simple dichotomie sur l'intervalle de revisions identifié comme celui qui introduit le bug.
  
  >Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).
  
  Bah oui, mais Mercurial n'a pas eu de Linus Torvalds à sa tête. Et pour un projet, un grand nom comme Linus Torvalds, ça donne envie de s'y pencher... Surtout vu comme GIT a été présenté lors de son officialisation: "GIT remplaçant de BitKeeper pour la gestion des sources de noyau". Il est toujours plus agréable d'associer ses contributions à des projets de renom.
  
  <malife et avis perso>
  Moi ce qui m'avait attiré vers Mercurial, c'était la démarche constructive de Matt Mackal, qui essayait de montrer à Linus ses erreurs. Linus refusait d'écouter les arguments avancés. Linus a monopolisé les forces de dev autour d'un projet qui techniquement ressemble plus à un hack qu'à un vrai programme pensé et construit dans les règles de l'art. Ce n'est pas une critique gratuite et trollesque, mais GIT, c'est écris en C pour le coeur, perl, python et Posix Sh pour les porcelains... ca utilisait historiquement rsync qui a mis a genoux kernel.org, puis est passé à un daemon plus malin pour distribuer les changesets manquants entre repositories... le backend fichier tend a espacer dans des répertoires différents des sources qui sont proches lors d'un checkout (dû à l'adressage par hash)... puis remarquant l'inneficacité de la bête lorsque le dictionnaire possède trop d'entrées dans l'index, Linus a eu recours à des packs d'entrées qu'on doit prendre soin de bien maintenir. Ca me fait penser a une idee qui germait dans arch/tla depuis pas mal de temps qui consitait à grouper plusieurs changesets ensembles pour eviter le trashing d'inodes et le parcours inutile du filesystem lors des update et des synchro réseau...
  
  Bref pour moi GIT a le succès qu'on lui connais car il a été démarré par Linus Torvalds... s'il avait été publié par un illustre inconnu, il n'aurait pas tenu la comparaison en terme de fonctionnel avec Monotone, Arch/tla, bazaar 1.x, ou même Darcs, Il n'avait pour lui que sa rapidité à trouver les fichiers changés (man stat(2)).
  
  Matt Mackal a su réfléchir et concevoir quelque chose qui tout en proposant les mêmes fonctionnalités, avait une belle architecture, homogène, lisse. Et même si ce n'est pas codé en C oil of codaz (dédicace GCU Squad), Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
  </malife et avis perso>
  
  Donc au final on est globalement d'accord, mais nos points de vue diffèrent car nous sommes fan de deux projets concurrents :-) Que le meilleur gagne !
  - [^]Re: Mercurial, le fils caché de GIT grandit lui aussi
    
    Posté par Pinaraf (Jabber id, ) le 24/04/2006 à 20:45. (lien). Évalué à 2.
    Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
    Bientôt, on pourra compiler du code Python...
    http://codespeak.net/pypy/dist/pypy/doc/news.html
    Y'a des trucs pour traduire du code python en C, mais aussi en assembleur, Java (!), Javascript (je suis perplexe, j'ai pas trop contrôlé...). J'ai aussi vu des dossiers smalltalk et llvm dans leur SVN...

[^]Monotone, le père spirituel de git mûrit lui aussi

Posté par Vivi (page perso, ) le 25/04/2006 à 20:14. (lien). Évalué à 3.
Hop, moi aussi je profite de la news pour rappeler que monotone http://www.venge.net/monotone/ existe toujours. La version 0.26 est sortie il y a 2 semaines.

Linus s'est beaucoup inspiré de monotone pour l'architecture de git. En fait la première version de git utilisait pratiquement le même façon que monotone d'organiser les données. Ça a un peu divergé depuis mais les principes sont les mêmes.

Comparaison avec darcs ?

Posté par Xavier Maillard (Jabber id, page perso, ) le 24/04/2006 à 16:14. (lien). Évalué à 2.

Quelqu'un aurait deja utilise les deux et serait capable de me dire comment se tient darcs par rapport a git ?

[^]Re: Comparaison avec darcs ?

Posté par Lucas Bonnet () le 24/04/2006 à 16:47. (lien). Évalué à 4.
Les perfs de darcs s'effondrent pour les gros dépôts, de l'aveu même de l'auteur.
- [^]Re: Comparaison avec darcs ?
  
  Posté par Xavier Maillard (Jabber id, page perso, ) le 24/04/2006 à 16:49. (lien). Évalué à 1.
  Certes' les perfs ne sont pas le fort de darcs (meme sur des petits depots) mais hormis ce probleme, ca donne quoi ?
  - [^]Re: Comparaison avec darcs ?
    
    Posté par alexissoft (Jabber id, page perso, ) le 24/04/2006 à 18:40. (lien). Évalué à 5.
    C'est écrit en Haskell, donc c'est génial si tu veux le compiler sur une machine qui n'a pas le compilateur Haskell (faut le bootstrapper machin et tout).
    
    A part ça il a des idées vachement bien et c'est assez sympa à utiliser.

Les RVS décentralisés

Posté par TeXitoi (Jabber id, page perso, ) le 25/04/2006 à 12:07. (lien). Évalué à 1.

Comme personne lance le sujet...

Les DRVS se sont pris une grosse envollé lors de l'histoire BK/Git. Un grand nombre de projets était alors dispo avec des fonctionnalités plus ou moins évolué. Il était alors difficile de faire une comparaison à cause de l'évolution rapide et de la multitudes des offres.

Je me demandais donc quelle est l'état des lieux vu que je n'ai trouvé aucune comparaison lisible et efficace entre les DRVS. J'en appelle donc à vos impressions et remarques sur le sujet.

Personnellement, je fais une utilisation basique de bazaar-ng. Les impressions que j'ai sur les différents CRVS sont les suivants :
- Bazaar-ng : soutenu par un gros projet (Ubuntu), avec de bonnes idées et une interface facilement utilisable. Les performances sembles ne pas être au rendez-vous, mais il est prévu qu'il y aie une grosse amélioration rapidement. Il manque encore quelques fonctionnalités comme le taggage de révision et la signature (GPG) intégrée. Il n'y a pas encore de gros projet qui l'utilise.
- Git : C'est le joujou de Linus. très performant sous Linux, mais dès qu'on sort de cet environnement, les performances chutent. Le renomage de fichiers n'est pas vraiment présent. Ce projet est très en vogue à cause de la notoriété de Linus et de Linux. C'est un outils concu, développé et utilisé par/pour le noyau linux.
- Mercurial : Un Git en mieu. Portable, moins bidouille. Même problème sur le renomage de fichier. La communauté est par contre beaucoup moins développé, surement du au fait que mercurial n'a pas la même renommé que Git.
- svk : en complement à svn. Je connais pas du tout
- darcs : semble avoir lancé des idées interessantes et boulversé les mentalités. Il semble avoir des problèmes de performances assez importantes et il n'y a pas de (grosse) communauté autour à cause de son language de programmation, Haksel.
- Les autres (codeville, monotone, tla et surement d'autres) semblent être passé derrière la scène, et risque peut-être de disparaitre.

Merci de faire avancer le débat ;-)

[^]Re: Les RVS décentralisés

Posté par golum () le 25/04/2006 à 13:50. (lien). Évalué à 3.
euh question bête ca signifie quoi rvs ?

je connais
rcs : revision control system
vcs : version control sytem
cms: configuration management system

je vais quand même pas devoir tout retagger mes liens sous delicious :)
http://del.icio.us/krazybug/vcs
- [^]Re: Les RVS décentralisés
  
  Posté par TeXitoi (Jabber id, page perso, ) le 25/04/2006 à 13:56. (lien). Évalué à 0.
  VCS, Otant pour mois.
  
  J'ai mélangé CVS, RVS et VCS.
  
  alors un gros s/ RVS/VCS/g sur mon post du dessus.

[^]Re: Les RVS décentralisés

Posté par Boa Treize (page perso, ) le 25/04/2006 à 21:07. (lien). Évalué à 3.

- Git : C'est le joujou de Linus. très performant sous Linux, mais dès qu'on sort de cet environnement, les performances chutent.

Remplacer "Linux" par "Unix", remplacer "chûtent" par "baissent", et ne pas oublier que Windows ne brille pas de manière générale par les performances brutes de son système de fichiers, et que Cygwin n'arrange rien à l'affaire.

Bref, faut pas croire que Git se traîne en dehors d'Unix, mais il est moins rapide c'est vrai. Il y a eu un gros travail sur les performances sous Cygwin, les principaux problèmes ont été éliminés.

Le renomage de fichiers n'est pas vraiment présent.

Et il n'est pas vraiment nécessaire. C'est CVS qui a obsédé tout le monde avec la gestion du renommage, puisque sous CVS renommer signifie perdre l'historique. Ce problème est énormément minoré quand on gère des changesets. De plus, quand on y regarde de plus près, le renommage de fichiers entiers n'est pas tant fréquent que la copie et le déplacement de portions de code.

Git permet bien sûr de renommer un fichier avec une petite commande toute simple (git-mv). Il n'enregistre pas cette information (l'opération de renommage), mais il permet de détecter automatiquement le renommage et la copie de portions de fichiers, et ça, c'est beaucoup plus intéressant.

Par exemple, entre Git v0.99.1 et v1.0rc4 (purement au hasard), entre autres très nombreuses modifications :

* La moitié de checkout-cache.c s'est retrouvée dans checkout-index.c
* convert-cache.c a été renommé en convert-objects.c
* pull.h a été renommé en fetch.h
* Une bonne partie de ssh-push.c a été copiée dans ssh-upload.c

Ligne de commande :
git-diff-tree -M -C --diff-filter=RC --find-copies-harder v0.99.1 v1.0rc4

Affichage :
(assez moche -- c'est une commande de bas niveau)

C'est sûr que cette fonctionnalité là n'est pas encore très user-friendly, mais elle est là et elle est bien utile.

Ce projet est très en vogue à cause de la notoriété de Linus et de Linux.

S'il maintient sa vogue, c'est aussi par sa qualité, et par effet boule de neige : bon développeurs, bon code et bonne ambiance = encore plus de bons développeurs et de bon code.

C'est un outils concu, développé et utilisé par/pour le noyau linux.

Pas uniquement. Comme le dit Junio Hamano, le mainteneur de Git, Linux n'est "que" le principal client de Git. Linux est important, mais pas au point de compromettre Git.

- Mercurial : Un Git en mieu.

Euh... non. Extrêmement similaire (à égalité technique avec Git pour OpenSolaris qui vient de les évaluer, et pourtant Git c'est GNU/Linux, et les développeurs d'OpenSolaris ne sont pas super fans des outils GNU et de Linux) (OpenSolaris a préféré Mercurial pour des raisons de poil brillant et d'un support promis par un développeur-clé de Mercurial).

moins bidouille

Ah non. La plupart de Git est bien écrit et bien conçu, tout comme la plupart de Mercurial. Dans les deux, il y a des recoins un peu bidouillés qui peuvent bénéficier d'un petit coup de balai.

- darcs : semble avoir lancé des idées interessantes et boulversé les mentalités.

Des idées intéressantes, tout à fait, bouleversé les mentalités, faut pas exagérer quand même. Il a par contre été le premier à ma connaissance à montrer à quel point on pouvait faire une interface claire et facile à apprendre (une leçon que Mercurial a bien compris) et à mettre ses données dans un sous-répertoire local (plutôt que dans une arborescence à part centralisée pour tous les projets hébergés sur la machine, genre cvsroot etc.). Git et Mercurial ont repris cette excellente idée.

Il semble avoir des problèmes de performances assez importantes

Ah oui.

il n'y a pas de (grosse) communauté autour à cause de son language de programmation, Haksel.

Ben en fait il a toute la communauté Haskell, donc ça fait pas mal de gars très intelligents. Mais j'ai pas suivi ces derniers mois.

[^]Re: Les RVS décentralisés

Posté par agmk () le 30/04/2006 à 09:54. (lien). Évalué à 1.
Juste une petite remarque : c'est Haskell, pas "Haksel".

--
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Sortie de Git 1.3.0

Bugs

[^]Re: Bugs

Petite faute

Date

[^]Re: Date

[^]Re: Date

Mercurial, le fils caché de GIT grandit lui aussi

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

[^]Re: Mercurial, le fils caché de GIT grandit lui aussi

[^]Monotone, le père spirituel de git mûrit lui aussi

Comparaison avec darcs ?

[^]Re: Comparaison avec darcs ?

[^]Re: Comparaison avec darcs ?

[^]Re: Comparaison avec darcs ?

Les RVS décentralisés

[^]Re: Les RVS décentralisés

[^]Re: Les RVS décentralisés

[^]Re: Les RVS décentralisés

[^]Re: Les RVS décentralisés