Ok j'ai compris, en fait c'est exactement comme quand tu utilises mq sur mercurial (sauf que mq est plus generique car tu peux avoir plus d'un commit dans la serie).
hg qnew new_cset.diff
modifie a;
hg qref a
...
quand on est satisfait:
hg qdel -r tip # commit definitivement
Pour la lenteur tu dois confondre avec darcs ou monotone.
La grosse différence est dans le fait que mercurial conserve l'information de descendance au niveau des fichiers, alors que git ne le fait que au niveau du changelog.
Il est donc au contraire plus facile de trouver un ancêtre commun pour 2 révisions d'un même fichiers (dans tous les cas l'ancêtre commun se trouve de façon linéaire).
Egalement git ne stocke pas les informations de renommage ou de copie, mais il utilise une heuristique pour les detecter après coup, alors que mercurial les stocke.
Finalement le format de hg a été conçu avec comme idée de minimiser le nombre de seek (mettre a jour la copie de travail à n'importe quel revision se fait en O(total des tailles de fichiers), un commit se fait en O(1) seeks), le stockage était dès le début efficace (il a fallu attendre les packs pour que git ne prenne pas une place énorme).
Malgré le fait que hg soit écrit en python (avec le noyau en C), il n'a pas à rougir de git au niveau de la vitesse, certaines opérations sont plus longues avec git, d'autres avec hg.
On en a justement beaucoup entendu parlé quand c'était sorti sur fedora. D'ailleurs il y avait eu des débats enflammés car beaucoup voulaient que ce soit inclus dans 6.10 (sans networkmanager, wpa est pas vraiment newbie friendly) finalement c'est allé dans universe pour passer dans main avec feisty.
Bref tout ca pour dire qu'il faut pas juste lire les sites de la communauté ubuntu (fridge, planet, etc) mais aussi aller voir ailleurs (notamment fedora vu qu'ils paient des devs pour implementer de nouvelles choses, pas juste faire du packaging/polishing comme le fait souvent canonical)
Pareil, j'ai jamais touché à windows, j'avais des mac os 7 chez mes parents. La curiosité m'a poussé à installer linux quand j'ai eu mon premier ordi, et j'ai jamais eu besoin d'autre chose. Ca me ferait vraiment ch... d'utiliser autre chose (en tout cas quelque chose de pas unix), ce serait trop différent.
(Bon ok y'a aussi la philosophie, la facilité de modifier des logiciels et de programmer et aussi la connaissance sur le système qu'on peut acquérir beaucoup plus vite).
Surtout que google est justement connu pour ne pas offrir de salaires aussi élevé que les autres boites du secteur. Par contre il y a des avantages en nature (bouffe par exemple) et un intéressement par l'actionnariat.
En même temps gaim était (ça a peut être changé depuis) connu pour être particulièrement désagréable avec les developpeurs (voire les utilisateurs, par exemple le ban des gens de gentoo).
La plupart des projets libres ne ressemblent pas à ca.
Surtout de point de vue de certaines personnes, ce n'est plus du tout utile. En effet avec le nombre de core qui double tout les ans, des machines paralleles on va en trouver partout, pas la peine de rajouter du parallelisme a la mosix (en plus c'est pas particulierement efficace mosix). (Et puis le mec qui faisait openmosix il fait de la virtualisation maintenant non ? genre Xensource)
En même temps dans le domaine de la compilation, on ne peut que saluer leurs efforts sur llvm et le frontend C clang (qui vient d'être libéré, l'ensemble des efforts jusqu'a la libération du code ayant été fourni par Apple).
Moi j'ai au contraire l'impression qu'il y a de plus en plus de PMP qui supportent le ogg sans limite de bitrate (les lecteurs de iriver et iaudio par exemple). C'est surement du à l'augmentation de la puissance des puces, mais cela indique également une demande.
Le problème est souvent que la procédure est très codifié, il faut donc que free attende un certain temps avant de passer à l'étape suivante.
Je crois qu'en général c'est très rare qu'il s'écoule 2 mois avant l'ultime étape (visite d'un technicien free et FT en même temps). Il faut donc espérer que FT résolve le problème avant...
Et ne pas oublier que le code de mpd s'est *beaucoup* dégradé en 2 ans, j'y ai jeté un coup d'oeil recemment (ca faisait longtemps) et c'est vraiment très moche (et pas du tout wakeup friendly, il y a de jolis boucles de reveils rapide).
Au final j'ai plus d'espoir du coté d'une librairie standard à la gstreamer, histoire de pas reinventer la roue.
Si tu veux pas l'heberger toi même, et que ta licence est compatible (il n'y a que 7 licences possibles je crois), googlecode est plutot pas mal. J'ai re-découvert recemment et c'est pas mal foutu pour un minimum d'effort pour l'utilisateur (surtout par rapport aux *forge).
on pourrait avec un systeme de hash ( nom piece jointe, taille, md5 etc ) ne pas sauvegarder des pieces jointes identiques ( vous savez tout les mails que ce client vous envoie avec un fichier signature bmp identique à chaque fois. Et bien sur, vous devez garder le mail ... )
[^] # Re: git et mercurial
Posté par ribwund . En réponse au journal Sondage pour utilisateurs de git. Évalué à 2.
hg qnew new_cset.diff
modifie a;
hg qref a
...
quand on est satisfait:
hg qdel -r tip # commit definitivement
[^] # Re: git et mercurial
Posté par ribwund . En réponse au journal Sondage pour utilisateurs de git. Évalué à 2.
par exemple que se passe t'il si on fait:
on modifie a # a est deja tracked
git commit
[^] # Re: git et mercurial
Posté par ribwund . En réponse au journal Sondage pour utilisateurs de git. Évalué à 6.
Pour la lenteur tu dois confondre avec darcs ou monotone.
La grosse différence est dans le fait que mercurial conserve l'information de descendance au niveau des fichiers, alors que git ne le fait que au niveau du changelog.
Il est donc au contraire plus facile de trouver un ancêtre commun pour 2 révisions d'un même fichiers (dans tous les cas l'ancêtre commun se trouve de façon linéaire).
Egalement git ne stocke pas les informations de renommage ou de copie, mais il utilise une heuristique pour les detecter après coup, alors que mercurial les stocke.
Finalement le format de hg a été conçu avec comme idée de minimiser le nombre de seek (mettre a jour la copie de travail à n'importe quel revision se fait en O(total des tailles de fichiers), un commit se fait en O(1) seeks), le stockage était dès le début efficace (il a fallu attendre les packs pour que git ne prenne pas une place énorme).
Malgré le fait que hg soit écrit en python (avec le noyau en C), il n'a pas à rougir de git au niveau de la vitesse, certaines opérations sont plus longues avec git, d'autres avec hg.
sinon je ne sais pas de quel conversion tu parles, mais le kernel a un repo hg: http://www.kernel.org/hg/linux-2.6/
quelques liens:
Mercurial: http://www.selenic.com/mercurial/wiki/
l'excellent livre de Brian O'Sullivan: http://hgbook.red-bean.com/
(c'est pas encore la version finale, le livre est sous licence libre)
Site proposant un hébergement pour mercurial : http://sharesource.org/
[^] # Re: Révolution? Innovation....
Posté par ribwund . En réponse au journal *buntu révolutionne l'informatique. Évalué à 3.
Bref tout ca pour dire qu'il faut pas juste lire les sites de la communauté ubuntu (fridge, planet, etc) mais aussi aller voir ailleurs (notamment fedora vu qu'ils paient des devs pour implementer de nouvelles choses, pas juste faire du packaging/polishing comme le fait souvent canonical)
[^] # Re: ca ne me choque pas du tout...
Posté par ribwund . En réponse au journal ClamAV racheté par Sourcefire.... Évalué à 3.
[^] # Re: L'habitude, première des raisons.
Posté par ribwund . En réponse au journal Quelle est LA raison qui vous pousse à utiliser Linux ?. Évalué à 6.
(Bon ok y'a aussi la philosophie, la facilité de modifier des logiciels et de programmer et aussi la connaissance sur le système qu'on peut acquérir beaucoup plus vite).
[^] # Re: ou alors...
Posté par ribwund . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 2.
[^] # Re: Royalement?
Posté par ribwund . En réponse au journal être invité un week-end chez Google. Évalué à 2.
# mon serveur web ipv6 perso
Posté par ribwund . En réponse au journal ohio, le web facile. Évalué à 10.
# gaim
Posté par ribwund . En réponse au journal Retours d'expérience sur contributions au libre. Évalué à 10.
La plupart des projets libres ne ressemblent pas à ca.
[^] # Re: Point d'étonnement
Posté par ribwund . En réponse au journal freebox, télé et non dégroupés. Évalué à 6.
[^] # Re: Nouvelle Generation d'occasion
Posté par ribwund . En réponse au journal Une offre étudiant avec Linux. Évalué à 3.
# .
Posté par ribwund . En réponse au journal Arrêt du projet OpenMosix. Évalué à 2.
[^] # Re: C'est assez courrant chez Apple
Posté par ribwund . En réponse au journal Apple embauche le créateur de CUPS. Évalué à 2.
# Flash Player
Posté par ribwund . En réponse au journal La fin de Ogg Vorbis?. Évalué à 2.
[^] # Re: free
Posté par ribwund . En réponse au journal Geonumbers. Évalué à 2.
Je crois qu'en général c'est très rare qu'il s'écoule 2 mois avant l'ultime étape (visite d'un technicien free et FT en même temps). Il faut donc espérer que FT résolve le problème avant...
[^] # Re: J'ai peur de ne pas avoir bien compris...
Posté par ribwund . En réponse au journal Les polics de caractère sous Linux - du neuf !. Évalué à 3.
J'ai 96dpi, subpixel, full hinting comme config (c'est vrai que les autres modes de hinting sont flous par contre).
[^] # Re: Pourquoi des accéléromètres ?
Posté par ribwund . En réponse à la dépêche Un téléphone libre : OpenMoko. Évalué à 2.
[^] # Re: La même rengaine...
Posté par ribwund . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 4.
Et pour se connecter "simplement", il suffit d'utiliser NetworkManager :)
[^] # Re: Merdre
Posté par ribwund . En réponse à la dépêche Jajuk, l'organisateur de collection musicale recherche des développeurs. Évalué à 2.
Au final j'ai plus d'espoir du coté d'une librairie standard à la gstreamer, histoire de pas reinventer la roue.
[^] # Re: Pour une extension du fichier !
Posté par ribwund . En réponse au journal Fichage ADN de masse. Évalué à 5.
[^] # Re: Ou alors...
Posté par ribwund . En réponse au journal Pouvoir gérer roadmap + todo-list + remontées de bugs.... Évalué à 3.
# git
Posté par ribwund . En réponse au journal Maildir, Mbox et autres. Évalué à 3.
on pourrait avec un systeme de hash ( nom piece jointe, taille, md5 etc ) ne pas sauvegarder des pieces jointes identiques ( vous savez tout les mails que ce client vous envoie avec un fichier signature bmp identique à chaque fois. Et bien sur, vous devez garder le mail ... )
Ca ressemble au systeme de git ca :)
# noscript
Posté par ribwund . En réponse au journal Adblockblockblock : l'anti-anti-anti-pub. Évalué à 6.
[^] # Re: Réseau
Posté par ribwund . En réponse au journal Test Ubuntu 7.04 (Feisty). Évalué à 4.