1.0 et 2.0 (Cassandra et Mercurial)

Posté par  (site web personnel) . Modéré par baud123. Licence CC By‑SA.
Étiquettes :
16
7
nov.
2011
Technologie

Des versions toutes rondes de logiciels libres sont tout juste sorties : la 1.0 de Cassandra, et la 2.0 de Mercurial.

N. D. A. : Merci à GeneralZod pour avoir contribué à cette brève.

Apache Cassandra 1.0

Le projet Apache Cassandra a publié la version 1.0.0 de son logiciel libre. Pour rappel, Cassandra est une base de données non‐SQL (NoSQL), sous forme de paires clé‐valeur, sous licence Apache 2.0. Initiée par Facebook et utilisée par Twitter, Digg et Reddit, Cassandra est super‐extensible et conçue pour fonctionner sur des grappes de serveurs (clusters).

Mercurial 2.0

Mercurial version 2.0 a été publiée. C’est un système de gestion de versions décentralisée sous UNIX (et donc GNU/Linux) et Windows, distribué sous licence GPL v2. Des fonctionnalités majeures on été ajoutées, et des nouveautés font leur apparition dans le cœur et les extensions.

Tous les détails dans la seconde partie.

 Apache Cassandra 1.0

Les apports majeurs :

  • compression des données sur disque ;
  • amélioration de la gestion de la mémoire ;
  • meilleure gestion de l’espace disque ;
  • nouvelle stratégie optionnelle de compactage nivelé ;
  • hinted handoffs améliorés ;
  • beaucoup d’améliorations des performances, du langage CQL (Cassandra Query Language), de la réparation, une administration plus facile, etc..

Mercurial 2.0

Fonctionnalités majeures

  • nouvelle commande graft qui permet de faire du picorage (cherry picking), c’est‐à‐dire d’importer une ou plusieurs révisions d’une autre branche. Par rapport à l’extension standard transplant, graft s’appuie sur les fonctionnalités de fusion de code interne à Mercurial, et est donc plus robuste ;
  • nouvelle extension largefiles. Celle‐ci permet d’optimiser le versionnage des fichiers binaires en ne stockant que le condensat de ceux‐ci.

Nouveautés Core

  • commit : échoue si il y a des changements non « commités » dans les sous-dépôts. Pour les commits récursifs, il faudra utiliser l’option « -S » ;
  • help : l’aide en ligne fournit désormais des exemples d’utilisation en faisant appel à « help -v » ;
  • import : possibilité d’éditer les messages de commits en utilisant l’option « --edit » ;
  • revset :
    • la bisection supporte plus d’alias,
    • ajout de l’option courte « -C » pour « --no-backup » ;
  • log : ajout du nouveau style bisect qui affiche le statut bisection ;
  • hgweb : nouveau paramètre web/logoimg pour personnaliser le logo de la visionneuse Web ;
  • subrepo : les révisions sont récupérés à la demande lors de l’archivage des sous‐dépôts.

Nouveautés extensions

  • color : ajout des styles pour les libellés (tags) ;
  • convert : prise en compte des marque‐pages (équivalent des branches git) dans les filemaps ;
  • eol :
    • ajout du nouveau paramètre « eol.fix-trailing-newline »,
    • le paramètre « eol.only-consistent » peut être spécifié dans le fichier « hgeol » ;
  • export : ajout du modèle « %m » aux chaînes de formatage (1re ligne du message de commit) ;
  • mq : la commande qqueue affiche le nom de la queue courante ;
  • rebase :
    • ajout de l’option « --edit »,
    • ajout de l’option « --rev »,
    • possibilité de se rebaser sur un ancêtre ;
  • share : ajout de la commande « unshare » ;
  • transplant : ajout de l’option « --edit ».

Aller plus loin

  • # Mercurial.. pour les nuls ça marche aussi ?

    Posté par  . Évalué à 6.

    j'ai fait l'expérience de migration de notre petit groupe de travail d'une abomination absolue (Microsoft SourceSafe -- SourceUnsafe pour les intimes) vers SVN en 2004.. et avec un petit travail de rééducation de mes collègues et patrons, tout s'est relativement bien passé.

    Aujourd'hui je pousserai bien mes collègues à considérer un basculement progressif vers Mercurial, pour résoudre les "merge" de plus en plus fréquents et les branches à maintenir, et le fait qu'on bosse sur plusieurs sites....

    quelqu'un a des retours d'expérience sur ce type de migration ? voire un bon bouquin pour les pro qui ne sont pas forcément spécialistes ?

    • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

      Posté par  . Évalué à 0.

      Ou sinon tu peux aussi utiliser Git ;).

      « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

      • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

        Posté par  . Évalué à 8.

        Ou sinon tu peux aussi utiliser Git ;).

        Tu lui vends la formation "Git pour les nuls" derrière ? Parce que Git c'est super puissant, mais son interface utilisateur est à chier. Mercurial est un poil plus cohérent et impose plus de gardes-fous (la réécriture d'historique n'est pas mongol-proof, la plupart comprendront jamais l'intérêt de la staging area, etc...)

        • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

          Posté par  . Évalué à 3.

          Il y a des concepts surprenant dans mercurial quand on viens de git. J'ai commencé en utilisant git parce que c'est bien et que tout le monde en parle. J'ai il y a pas longtemps voulu essayer mercurial qui possède pleins de bonnes choses (modulaire, portable, ...). Il y a un truc qui m'a bien surpris c'est le fait qu'il envoie toutes les branches sur le serveur (alors que sous git on a l'habitude d'utiliser des branches pour tout et n'importe quoi). D'après la dépêche j'aurais du utiliser des marques-pages.

          Pour le moment n'ayant pas réussi à détruire une branche pour commiter uniquement ce que je voulais j'ai remis cet apprentissage à plus tard.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

          Posté par  . Évalué à 2.

          Deux vidéos en français sur Git que j'ai pas mal appréciées:
          - Vidéo 1 : www.parleys.com/#st=5&id=2366
          - Vidéo 2 : www.parleys.com/#st=5&id=2368

          Les présentations sont réalisées par Sébastien Douche http://linuxfr.org/users/sdouche (merci à lui !) qui anime le blog http://blog.gitfr.net/ où l'on trouve pas mal d'informations sur Git en français.
          J'ai eu l'occasion de participer à un atelier avec lui sur Git et j'ai appris pas mal de choses !

        • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

          Posté par  . Évalué à 2.

          Parce que Git c'est super puissant, mais son interface utilisateur est à chier

          Git n'a pas qu'une seule interface utilisateur. Je te conseille gitg pour GNOME ou qgit pour KDE.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

      Posté par  . Évalué à 5.

      http://hginit.com/

      Et sinon il y a d'autres bouquins, notamment chez O'reilly, et en ligne il y a http://hgbook.red-bean.com/ .

    • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

      Posté par  . Évalué à 5.

      Nous on a migré tous nos projets de SVN à Mercurial il y a 2 ans environ et nous n'avons eu aucun soucis. Je me suis contenté d'un script de migration qui il me semble (mais je peux me tromper), était fourni avec la release de Mercurial après avoir consulté quelques docs/discutions online.

      En gros j'ai l'importation c'est déroulée au poil. Rien à signaler. Enfin si, que du bonheur depuis niveau gestion des branches et des merges !

      • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

        Posté par  . Évalué à 1.

        c'est rassurant, pour le niveau technique !

        après pour le niveau pratique, le truc c'est aussi d'avoir un système ''mongol-proof'' pour reprendre l'expression ci-dessus.. et suffisamment de documentation claire pour que l'utilisateur de base ne fasse pas n'importe quoi / comprenne ce qui se passe (Sachant que se payer une formation pour 10 personnes.. oulala non, c'est pas possible).

        En tout cas je vais mater les docs évoquées plus haut, ça a l'air intéressant, tout ça.

        • [^] # Re: Mercurial.. pour les nuls ça marche aussi ?

          Posté par  (site web personnel) . Évalué à 4.

          après pour le niveau pratique, le truc c'est aussi d'avoir un système ''mongol-proof'' pour reprendre l'expression ci-dessus.. et suffisamment de documentation claire pour que l'utilisateur de base ne fasse pas n'importe quoi / comprenne ce qui se passe (Sachant que se payer une formation pour 10 personnes.. oulala non, c'est pas possible).

          Je ne connais pas Hg mais voulais témoigner de mon passage de SVN à GIT.

          Après avoir appris et utilisé longtemps CVS, je suis assez naturellement passé à SVN lorsque celui-ci a gagné en popularité (parceque je ne fais pas la liste de SCM toutes les semaines!). Devant souvent travailler off-line et sur plusieurs sites différents, j'ai rapidement souffert des limitations que pose SVN pour ce mode de travail et ai connu de nombreux déboires avec SVK (une sorte de sur-couche SVN facilitant notamment le travail off-line). Ayant été plusieurs fois le témoin de la popularité de GIT et entendu qu'il était décentralisé — donc parfait pour moi — je me suis lancé dans la migration.

          Tout s'est passé avec assez de bonheur et je suis aujourd'hui un utilisateur de GIT comblé. La documentation a toujours rapidement répondu à mes questions, cependant je reconnais volontiers que la réputation de logiciel difficile qu'auréole GIT n'est pas complètement imméritée. Je crois que cela tient surtout au fait que les opérations qu'offre l'interface de GIT sont moins abstraites que celles offertes par SVN. D'un côté SVN est moins flexible que GIT mais le travail avec SVN suit un workflow dont chaque étape possède une commande SVN correspondante et suffisamment bien documentée. De l'autre coté, les ordres GIT ne correspondent pas forcément à des étapes d'un workflow défini a l'avance, donc utiliser GIT peut nécessiter de définir un workflow pour le projet et de traduire ses étapes en commandes GIT pour que même les novices s'y retrouvent.

  • # CQL

    Posté par  (site web personnel) . Évalué à 4.

    On a une démo d'une console CQL ici si ça intéresse des gens (possible qu'on rajoute des données plus intéressantes dans les jours qui viennent) : http://cqldemo.acunu.com/
    Oui, c'est comme du SQL avec des trucs en moins de ce que j'ai compris. ça simplifie beaucoup l'utilisation par rapport à l'API natif.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # NoSQL != non-sql

    Posté par  (site web personnel) . Évalué à 2.

    Enfin si je dis pas de connerie mais NoSQL ca veux dire Not Only SQL. Donc c'est pas juste dire pas de SQL.

    • [^] # Re: NoSQL != non-sql

      Posté par  . Évalué à 6.

      NoSQL ça veut recouvre principalement tout et n'importe quoi entre des bases orientées colonnes, document JSON, etc.

      C'est à mettre au mettre au même rang que les buzzwords tels qu'AJAX, WEB2.0, agile,...

    • [^] # Re: NoSQL != non-sql

      Posté par  . Évalué à 7.

      NoSQL ça désigne les bases non-SQL (comprendre les bases non-relationnel) le "Not Only SQL" c'est arrivé plus tard pour ménager la sensibilité des chauves.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: NoSQL != non-sql

          Posté par  . Évalué à 6.

          Pour un dissaïdor, « relationnel » n’a rien à voir avec la technique mais avec les RH. En revanche, « SQL », c’est le truc auquel il entrave que dalle et qui lui coûte cher (soit parce qu’il a des gens qui coûtent cher pour s’en occuper et que ceux-ci lui font peur, soit parce qu’il a des gens qui ne lui coûtent rien pour s’en occuper et qu’il a beaucoup de problèmes avec et que c’est la principale raison du retard de ses projets, soit, pire, parce qu’il paie cher et que ça ne fonctionne pas quand même).

        • [^] # Re: NoSQL != non-sql

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Et avec du NoSQL, on s'en sort sans trop de séquelles.

  • # Nettement moins populaire que Git

    Posté par  (site web personnel) . Évalué à 2.

    Si on en croit le nombre de commentaires postés, Mercurial a un sérieux déficit en popularité par rapport à Git. Personnellement je cherche à remplacer Subversion (qui nous sert pour des projets .Net) au boulot. Naturellement j'étais parti du Mercurial qui est bien supporté (support direct avec Gui + intégration dans Visual Studio) sous Windows.

    Quand je vois comment Git attire tous les commentaires, je ne vois qu'une solution attendre que Git soit correctement intégré sous Windows pour éviter de faire deux portages à la suite.

    Ce post n'est pas un troll, c'est une réflexion que je me fais depuis la sortie de cette dépêche.

    • [^] # Re: Nettement moins populaire que Git

      Posté par  . Évalué à 4.

      Si Mercurial comble tes besoins, il n'y a pas de raisons de passer à Git pour le fun, surtout si tu doit attendre un support pour Windows qui n'a pas l'air d'être la priorité des développeurs.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Nettement moins populaire que Git

      Posté par  . Évalué à 3.

      A ta place je ne me poserais pas la question. Sous windows git a de gros problèmes de support et ça n'a pas l'air d'être près de changer. C'est pas comme si mercurial avait un avenir incertains.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.