jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Code

Liens connexes

L'annonce de la 1.0 (357 hits)
Homepage (830 hits)
Téléchargement (135 hits)
La documentation (279 hits)
La naissance du projet (181 hits)

Dépêche modérée par

NoNo

Dépêche éditée par

Code : Mercurial 1.0

Posté par Edouard Gomez (page perso, ). Modéré le 25 mars 2008.

Après plus de trois ans de développement, Matt Mackall, développeur principal de Mercurial, annonce sur la liste de développement du projet que la version 1.0 est enfin prête. Mercurial est un gestionnaire de source décentralisé écrit en Python dont les objectifs principaux sont :

Facile à maîtriser et utiliser ;
Léger ;
Bonne tenue en charge (« scalabilité ») ;
Facile à personnaliser.

Il est livré avec une excellente documentation qui permet bien sûr de découvrir l'ensemble des commandes du programme mais aussi de mieux appréhender la gestion de source décentralisée avec ses nombreux avantages. Ce gestionnaire fonctionne à la fois sous nos Unix préférés et sous Windows. Il intègre de plus un convertisseur de dépôt de source permettant de reprendre l'historique de ses anciens projets CVS, SVN, Git, Darcs, Monotone, et GNU Arch/Bazaar 1.x.

Laissez-vous tenter par cet excellent outil qui ne pêche que par le manque de publicité qu'il génère face à Bazaar ou Git.

L'annonce de la 1.0 (357 hits)
Homepage (830 hits)
Téléchargement (135 hits)
La documentation (279 hits)
La naissance du projet (181 hits)

> Lire la dépêche (36 commentaires, moyenne: 3,4).

Voici un peu plus de détail concernant les fonctionnalités de Mercurial.
Rapide

Grande rapidité grâce à son format de stockage orienté delta-compression ;
Optimisé pour des accès rapides ;
Indexation croisée des changesets et fichiers ;
Protocoles HTTP et SSH optimisés en terme de bande passante et charge processeur.

Tenue en charge (« Scalable »)

Le modèle de développement distribué supporte un nombre illimité de développeurs ;
Permet la fusion arbitraire du travail de plusieurs développeurs ;
Son niveau de performance ne se dégrade pas avec un grand nombre de fichiers ou changesets ;
Pas d'attente sur verrou posé.

Robuste

Garantie d'intégrité des données du dépôt de source grâce à l'utilisation de sommes de contrôle SHA1 ;
Modèle de stockage « Append-only » avec un journal de transaction ;
Vérification du dépôt de source rapide ;
Format de stockage facilitant les sauvegardes.

Facile à utiliser

Ceux maîtrisant déjà CVS ou un autre gestionnaire de source, connaissent sûrement déjà la plupart des commandes ;
Aide en ligne intégrée ;
Fournit une interface web indépendante ;
Fonctionne avec plusieurs interfaces graphiques (TortoiseHG sous Windows par exemple).

Facile à mettre en place

Compatible UNIX, Mac OS X, et Windows ;
Plugin de conversion pour les gestionnaires de sources les plus communs ;
Permet des modèles d'usage variés ;
Supports de « hooks » et extensions définis par l'utilisateur.

Libre

Source disponible sous la GPL v2 ;
Soutenu et développé par une communauté active.

Mais rien n'est plus parlant que la liste grandissante de projets qui n'hésitent pas à basculer sous ce gestionnaire de sources :

La plupart des projets de chez Sun : OpenJDK, OpenSolaris, etc. ;
Mozilla ;
Des sous-projets du noyau: ALSA (pilotes son), LinuxTV (pilotes TV).

Alors oui, Mercurial n'est pas aussi exposé médiatiquement que Git ou Bazaar mais avec cette dépêche, j'espère que certains d'entre vous prendront le temps de découvrir Mercurial, de le comparer et donc de l'adopter :-).

N'oubliez pas de faire un tour sur le Wiki pour en savoir plus.

Freehg : Hébergement gratuit

Posté par chicha () le 25/03/2008 à 10:50. (lien). Évalué à 5.

Je me permet de rajouter que http://freehg.org a vu le jour récemment.
C'est une platforme d'hébergement gratuite (et libre) permettant à n'importe qui d'héberger n'importe quel(s) projet(s) mercurial.

Le tout avec la simplicité et le design qu'on aime chez mercurial.

C'est un projet indépendant de HG initié par Matthew Marshall.

[ Répondre ]

[^]Re: Freehg : Hébergement gratuit

Posté par -mat () le 25/03/2008 à 11:20. (lien). Évalué à 4.
À noter aussi l'hébergement de dépôts mercurial sur : http://sharesource.org/

[ Répondre ]
- [^]Re: Freehg : Hébergement gratuit
  
  Posté par Nÿco (Jabber id, page perso, ) le 25/03/2008 à 12:00. (lien). Évalué à 8.
  Pas très futé comme nom, ça ressemble au programme « Shared Source » de Mircosfot, qui je le rappelle n'a pas pour vocation de faire du libre, de près ou de loin.
  
  --
  Jabber ID : xmpp:Nyco@jabber.fr
  
  [ Répondre ]
  - [^]Re: Freehg : Hébergement gratuit
    
    Posté par gnu_castor (Jabber id, page perso, ) le 25/03/2008 à 14:30. (lien). Évalué à 2.
    Pas très futé comme nom
    
    Sisi ! les avocats de Microsoft vont égayer leur vie :)
    
    [ Répondre ]

Autre "clients"

Posté par bidule () le 25/03/2008 à 11:10. (lien). Évalué à 4.

- xen est également développé sous mercurial.

- Coté kernel linux, il me semble qu'un dépot mercurial était synchronisé avec le dépot git principal: quelqu'un pour confirmer ?

[ Répondre ]

[^]Re: Autre "clients"

Posté par ribwund () le 25/03/2008 à 11:22. (lien). Évalué à 4.
Oui, le mirroir est à jour sur http://www.kernel.org/hg/linux-2.6/

[ Répondre ]

[^]Re: Autre "clients"

Posté par Éric (Jabber id, page perso, ) le 25/03/2008 à 12:37. (lien). Évalué à 1.
Mozilla est aussi passé à Mercurial d'après les annonces qu'ils ont faites

[ Répondre ]

deux questions .....

Posté par totof2000 () le 25/03/2008 à 11:54. (lien). Évalué à 4.

La gestion des versions se fait-elle "à la CVS" avec versionning sur le fichier, et non pas sur l'ensemble du projet, ou à la "subversion", avec versionning sur le projet complet ?

Est-il prévu pour gérer efficacement les fichiers binaires (style images, fichiers issus d'un tableur, etc ....) ?

[ Répondre ]

[^]Re: deux questions .....

Posté par ribwund () le 25/03/2008 à 12:37. (lien). Évalué à 5.
Sur l'ensemble du projet (comme tout les VCS distribués).

Pour les fichiers binaires, la seule contrainte est qu'ils tiennent en mémoire. Après l'algorithme de diff ne trouvera des ressemblances qui si on peut en trouver (par exemple c'est peu probable pour un .tar.gz).
Pour certains types de fichiers on peut avoir des performances excellentes à l'aide des filtres d'encodage/décodage.

Par exemple si le format d'un fichier est du texte compressé avec gzip, il suffit de le décompresser dans le filtre d'encodage et de le recompresser dans le filtre de décodage pour avoir de bonnes propriétés sur le diff.

[ Répondre ]

plugins ODT ?

Posté par ploum (page perso, ) le 25/03/2008 à 11:58. (lien). Évalué à 3.

Existe-t-il des gestionnaires de version qui supportent l'ODT ?

De manière générale, ce serait cool d'avoir des gestionnaires avec des plugins en fonction des type de fichier. Cela permettrait par exemple de gérer les diffs entre des images et ce genre de choses.

[ Répondre ]

[^]Re: plugins ODT ?

Posté par alenvers () le 25/03/2008 à 12:19. (lien). Évalué à 2.
Pour l'odt, c'est du texte (xml) donc, il ne doit pas avoir de problèmes.

Pour les images, il y a des formats de fichiers qui retiennent l'historique des changements...

[ Répondre ]
- [^]Re: plugins ODT ?
  
  Posté par Moonz () le 25/03/2008 à 13:20. (lien). Évalué à 5.
  Non, c'est du xml compressé en zip. Ce n'est pas la même chose.
  
  [ Répondre ]
  - [^]Re: plugins ODT ?
    
    Posté par Matthieu Moy (page perso, ) le 25/03/2008 à 14:02. (lien). Évalué à 2.
    Et c'est du XML "tout-sur-une-ligne", donc un diff bête et méchant dessus ne fait pas grand chose d'intéressant.
    
    [ Répondre ]
    - [^]Re: plugins ODT ?
      
      Posté par Auberon (page perso, ) le 25/03/2008 à 14:14. (lien). Évalué à 2.
      Il est possible d'enregistrer les fichiers ODT/XML avec des retour-chariots.
      Il suffit d'aller dans :
      menu Outils > Options > Chargement/Enregistrement > Général
      Décoche ensuite :
      Optimisation de la taille pour le format XML.
      
      [ Répondre ]
      - [^]Re: plugins ODT ?
        
        Posté par ribwund () le 25/03/2008 à 14:25. (lien). Évalué à 4.
        Ca change vraiment la taille leur truc ? Surtout si ils compressent le fichier apres...
        
        [ Répondre ]
        
        [^]Re: plugins ODT ?
        
        Posté par Auberon (page perso, ) le 25/03/2008 à 14:45. (lien). Évalué à 2.
        Personnellement, je ne sauvegarde jamais avec l'optimisation et je n'ai constaté aucune augmentation significative de la taille des fichiers.
        Effectivement, la compression atténue grandement une augmentation déjà peu importante en elle-même.
        
        [ Répondre ]
    - [^]Re: plugins ODT ?
      
      Posté par alenvers () le 25/03/2008 à 14:31. (lien). Évalué à 1.
      Probablement avec ça
      http://hgbook.red-bean.com/hgbookch10.html#x14-19700010
      
      Un
      gzip sur le fichier + un 's/></>\n</g' devrait faire l'affaire.
      
      Pour le faire proprement, il faudrait un diff qui fonctionne sur une arborescence (et pas sur les lignes). Mais bon, qui se propose de le faire car c'est un Gruiik-Gruiik ce genre de chose ? Un algo LCS (Longest Common Sequence) est vraiment simple par rapport à ça.
      
      La bonne question est cela vaut-il vraiment la peine de se crever à créer un utilitaire diff pour chaque type de fichier existant ? Traitons-les juste comme du binaire ou utilisons des formats adaptés.
      
      Pour ma part, c'est du LaTeX, donc, jamais eu ce type de problèmes.
      
      [ Répondre ]
      - [^]Re: plugins ODT ?
        
        Posté par Bozo le clown () le 25/03/2008 à 14:57. (lien). Évalué à 4.
        
        La bonne question est cela vaut-il vraiment la peine de se crever à créer un utilitaire diff pour chaque type de fichier existant ? Traitons-les juste comme du binaire ou utilisons des formats adaptés.
        
        La réponse est ... oui.
        Chaque format de fichier dispose de sa propre sémantique et ce n'est pas parce que tu disposes de comparateur/merger de fichiers XML que tu es en mesures d'apprécier un même changement qui apparait en plusieurs endroits d'un même fichier.Il y a de réels risques de corruption de fichiers.
        
        Clearcase implémente ca depuis toujours en permetttant d'associer à chaque type de fichier de se voir associer un outil de comparaison/fusion adapté. Malgré tous ses défauts, la façon dont il aborde cette problématique reste un de ses principaux attraits par rapport à la concurrence.
        Ainsi tu peux comparer des fichiers Word graphiquement (en attendant ODT) mais aussi des fichiers Rose ou même des arborescence complètes.
        
        Des initiatives émergent pour proposer des comparateurs pour les types de formats qui soient indépendantes du gestionnaire de version (cf. EMF Compare par exemple http://www.eclipse.org/modeling/emft/?project=compare#compar(...) Il serait donc dommage que les VCS ou les outils clients le négligent.
        ODT ne devrait donc pas déroger à la règle et proposer lui-même cette fonctionnalité (plugin OpenOffice par exemple).
        
        [ Répondre ]
        
        [^]Re: plugins ODT ?
        
        Posté par alenvers () le 25/03/2008 à 15:15. (lien). Évalué à 4.
        >Chaque format de fichier dispose de sa propre sémantique
        
        Ce que je veux dire c'est que justement cette sémantique n'est pas si évidente. Cela semble simple sur papier, mais comparer des fichiers n'est pas trivial voire complètement voué à l'échec.
        
        Quelques exemples :
        - Prenons 2 images dont la différence est juste un correction de luminosité : comment faire un diff (tous les points ont changés) ?
        - Prenons 2 fichiers xml dont la différence est
        <it>Italics</it> devient <it>Ita<bd>li</bd>cs</it>
        Le texte est le même mais la présentation pas que sort le diff ?
        - Prenons 2 fichiers xml
        <item>item1</item>
        <item>item2</item>
        et
        <item>item2</item>
        <item>item1</item>
        
        Sont-ils identiques ou pas si l'ordre n'a pas d'importance ?
        
        Et encore, j'ai choisi des cas extrêments simple. Dans des cas rééls, je n'ose même pas imaginer les problèmes possible.
        
        [ Répondre ]
        
        [^]Re: plugins ODT ?
        
        Posté par Bozo le clown () le 25/03/2008 à 15:42. (lien). Évalué à 3.
        Et ma réponse est donc.
        Qui connait le mieux la sémantique de son fichier que l'outil qui l'exploite ?
        
        L'outil doit fournir son propre comparateur/mergeur qui accepte en paramètre 2 (comparaison) ou 4 (merge 3 contributeurs) versions de fichiers selon que tu souhaites comparer ou merger.
        Dans ton cas, il présente graphiquement la différence, te propose de choisir la combinaison et il assure la cohérence du changement. Le cas du merge des fichiers texte à plat (sources) qui ne présument pas de la sémantique n'est qu'un cas particulier. Pourquoi vouloir le généraliser à tous types de fichiers.
        Ainsi même un fichier java a une sémantique différente d'un fichier python et si un outil VCS les traite de façon identique on peut très bien imaginer qu'il passe la main à un IDE qui connait mieux la structure de ce fichier et est capable d'apporter plus d'intégration tout en n'étant pas trop intrusif (par exemple l'ajout d'une accolade ouvrante dans un merge de .java s'accompagne forcément de l'ajout d'une accolade fermante pour marquer la mise en bloc). L'IDE en est capable. encore faut il que le VCS lui passe la main dans de bonnes conditions.
        
        Ainsi on reste indépendant de l'outil VCS pour peu qu'il respecte le protocole.
        A chacun ses responsabilités.
        
        C'est ce que j'attends d'ODF (mais peut-être qu'OpenOffice le propose déjà)
        
        [ Répondre ]
- [^]Re: plugins ODT ?
  
  Posté par Raphaël SurcouF (Jabber id, page perso, ) le 25/03/2008 à 14:27. (lien). Évalué à 7.
  Non seulement c'est du XML compressé en ZIP, mais si tu lis couramment le XML des documents OpenOffice.org, moi pas. Je ne me vois pas faire un diff entre deux versions d'un même document pour savoir ce que j'ai pu modifier.
  Ce qui manque dans tous les VCS, c'est un outil de diff pour les ODT, point.
  
  [ Répondre ]
  - [^]Re: plugins ODT ?
    
    Posté par Albert () le 25/03/2008 à 17:59. (lien). Évalué à 1.
    un truc comme ca?
    
    http://extensions.services.openoffice.org/project/OOoSVN
    
    (par contre on dirait que cela n'est plus trop developpe...)
    
    [ Répondre ]
    - [^]Re: plugins ODT ?
      
      Posté par Thomas Douillard () le 25/03/2008 à 18:53. (lien). Évalué à 2.
      En suivant quelques liens il semble que le projet soit devenu : http://odfsvn.sourceforge.net/
      
      [ Répondre ]

[^]Re: plugins ODT ?

Posté par Clément David (Jabber id, page perso, ) le 25/03/2008 à 13:23. (lien). Évalué à 4.
D'après ce qui est dit juste au dessus, il est apparemment possible d'utiliser des filtres avant et après le diff.

Utilise alors un filtre ZIP/UNZIP pour le type ODT et le tour est joué.

--
C# (sans runtime) + GObject = Vala

[ Répondre ]

[^]Re: plugins ODT ?

Posté par chicha () le 25/03/2008 à 13:33. (lien). Évalué à 5.
Mercurial (Hg) supporte l'ODT, et donne ici une astuce pour afficher les diffs :

http://www.selenic.com/mercurial/wiki/index.cgi/HandlingOpen(...)

[ Répondre ]

[^]Re: plugins ODT ?

Posté par Matthieu Moy (page perso, ) le 25/03/2008 à 13:59. (lien). Évalué à 3.
http://www-verimag.imag.fr/~moy/opendocument/

(même texte que celui cité plus bas sur le Wiki de Mercurial)

En fait, à partir du moment où on a un truc un peu flexible, et qu'on connait odt2txt, c'est assez facile de générer des diffs sur ces fichiers.

Par contre, c'est un diff visuel, mais hors de question de l'appliquer avec patch. Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.

[ Répondre ]
- [^]Re: plugins ODT ?
  
  Posté par -mat () le 25/03/2008 à 14:22. (lien). Évalué à 2.
  
  Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.
  
  Il y a http://tdm.berlios.de/3dm/doc/index.html
  C'est un peu rugueux... Mais j'espère bien l'utiliser ou m'en inspirer à court ou moyen terme (comprendre, dans longtemps ou jamais.... vu l'état d'avancement de mes projets perso)
  
  [ Répondre ]

Netbeans est aussi developpe sous mercurial.

Posté par guignome (page perso, ) le 25/03/2008 à 14:51. (lien). Évalué à 4.

A noter le suport de Hg integre dans netbeans: http://wiki.netbeans.org/MercurialVersionControlScreenshots (screenshots :-))

[ Répondre ]

Mercurial, c'est bon, mangez-en

Posté par Philippe Fremy (page perso, ) le 25/03/2008 à 19:46. (lien). Évalué à 5.

J'ai toujours du mal à comprendre pourquoi ce gestionnaire de version ne reçoit pas plus de publicité.

Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.

En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS

Par exemple :
http://sources.freehackers.org/hg.cgi

Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...

Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.

La video côté google présentant mercurial :
http://video.google.com/videoplay?docid=-7724296011317502612(...)

Elle génère moins de buzz que celle de Linus, mais tel est le sort de Mercurial : moins de buzz mais des trucs qui marchent !

--
phil.freehackers.org

[ Répondre ]

[+] [^]Re: Mercurial, c'est bon, mangez-en

Posté par alexissoft (Jabber id, page perso, ) le 25/03/2008 à 23:21. (lien). Évalué à -1.
Perso, j'ai pas mal utilisé Mercurial. J'ai jamais pu piger le système de branchages et de merges, alors que git fait ça comme un charme.

Le problème de Mercurial c'est que c'est un fouilli monstre, il y a 3600 commandes et de plugins dans tous les sens qui se tapent dessus. Suffit de faire un hg help pour voir le désastre.

Du coup, je suis passé à git. Même si j'adorais Mercurial.

[ Répondre ]
- [^]Re: Mercurial, c'est bon, mangez-en
  
  Posté par ribwund () le 25/03/2008 à 23:46. (lien). Évalué à 4.
  Les commandes ca depend de la distro, par défaut aucun plugin n'est activé, après si debian active tous les plugins c'est normal qu'il y ait beaucoup de commandes.
  
  Si l'on lance hg sans argument, uniquement les commandes importantes sont listés (une vingtaine alors que j'ai quelques extensions d'activés).
  
  Je pense que la meilleure chose à faire est de n'activer les plugins que si l'on en a besoin (et que ceux dont on a besoin).
  
  (git a quand meme plus de 130 sous-commandes, bien plus que mercurial, avec tous les plugins il y a 75 commandes max)
  
  [ Répondre ]
- [^]Re: Mercurial, c'est bon, mangez-en
  
  Posté par Thomas Capricelli (Jabber id, page perso, ) le 27/03/2008 à 19:52. (lien). Évalué à 7.
  fouilli ? des millons de commandes ? On ne dois pas parler de la meme chose. C'est exactement le contraire qui m'a seduit avec mercurial.
  
  Apres avoir essaye git pendant plusieurs jours sans jamais rencontrer un truc simple ou intuitif, j'ai ete operationnel avec mercurial en 5 minutes. Vraiment 5 minutes, ce n'est pas juste une expression
  Avec git, j'ai du ouvrir des tas de docs/tutoriaux sur internet. Avec mercurial, meme pas. "hg help", et tout etait evident... J'ai utilise beaucoup d'outils de ce genre, proprietaires ou libres, et franchement, mercurial est le top du top, tres largement en avance sur tous les autres. git est pas mal, assez puissant, mais rien a voir en terme de facilite d'acces (et il ne marche pas sous windows.. oui, je sais bientot, presque, etc...mais pas maintenant.)
  
  Franchement, quand je tape "git<tab>" sur mon pc, j'suis trop content d'utiliser mercurial. La seule raison pour laquelle j'utilise encore un peu git, c'est pour avoir des branches locales de repository svn, sur mon portable.
  
  En plus de mes projets persos et professionnels, j'utilise les mirroirs mercurial pour le noyau linux, gcc et django. Ils prennent peu de place, malgre l'historique. (taille du 'repository' .hg inferieure a la taille d'un 'checkout'), et sont tres rapides.
  
  [ Répondre ]

[^]Re: Mercurial, c'est bon, mangez-en

Posté par Mildred (Jabber id, page perso, ) le 26/03/2008 à 12:33. (lien). Évalué à 2.
Dans la vidéo (qui date un peu maintenant) ils disent que la possibilité de cloner une partie seulement du repository allait bientôt arriver ... mais il semble que non en fait:

http://www.selenic.com/mercurial/bts/issue105

Pourtant, je pense que c'est quelque chose d'imortant. Je pense par exemple a KDE qui maintient des logiciels similaires ensemble. J'imagine que tout le monde n'a pas forcément envie de tout télécharger pour travailler juste sur une partie.

Et il y a aussi la possibilité de ne récupérer que les dernières révisions qui me semble pratique (lorsque le projet se développe):

http://www.selenic.com/mercurial/wiki/index.cgi/TrimmingHist(...)

mais je n'ai pas réussi a savoir si c'était implémenté ou non.

--
La Roue du Temps

[ Répondre ]
- [^]Google Summer of Code
  
  Posté par ribwund () le 26/03/2008 à 14:33. (lien). Évalué à 2.
  L'historique partielle et le clonage partielle sont potentiellement des projets Google Summer of Code.
  Donc pour les étudiants volontaires...
  
  http://www.selenic.com/mercurial/wiki/index.cgi/SummerOfCode
  
  [ Répondre ]

Projets qui l'utilisent

Posté par Olivier Faurax (Jabber id, page perso, ) le 26/03/2008 à 19:17. (lien). Évalué à 2.

Une rapide recherche m'a montré que Hg est notamment utilisé par Mozilla (pour FF4 et xulrunner 2) ainsi que par Sun pour la version Open Source de Java.
Il parait qu'OpenSolaris l'utilise aussi....

--
xmpp:ofaurax@jabber.fr

[ Répondre ]

[^]Re: Projets qui l'utilisent

Posté par Mildred (Jabber id, page perso, ) le 26/03/2008 à 19:24. (lien). Évalué à 4.
La news indiquait pourtant:

Mais rien n'est plus parlant que la liste grandissante de projets qui n'hésitent pas à basculer sous ce gestionnaire de sources :

* La plupart des projets de chez Sun : OpenJDK, OpenSolaris, etc. ;
* Mozilla ;
* Des sous-projets du noyau: ALSA (pilotes son), LinuxTV (pilotes TV).

--
La Roue du Temps

[ Répondre ]

Revenir en haut de page

Articles précédents : Code

Liens connexes

Dépêche modérée par

Dépêche éditée par

Code : Mercurial 1.0

Freehg : Hébergement gratuit

[^]Re: Freehg : Hébergement gratuit

[^]Re: Freehg : Hébergement gratuit

[^]Re: Freehg : Hébergement gratuit

Autre "clients"

[^]Re: Autre "clients"

[^]Re: Autre "clients"

deux questions .....

[^]Re: deux questions .....

plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

[^]Re: plugins ODT ?

Netbeans est aussi developpe sous mercurial.

Mercurial, c'est bon, mangez-en

[+] [^]Re: Mercurial, c'est bon, mangez-en

[^]Re: Mercurial, c'est bon, mangez-en

[^]Re: Mercurial, c'est bon, mangez-en

[^]Re: Mercurial, c'est bon, mangez-en

[^]Google Summer of Code

Projets qui l'utilisent

[^]Re: Projets qui l'utilisent