Ah ben moi je préfère largement un hg branch et un hg resolve
Je vois pas où est le pb ?
Ca comparé à un git fetch/update/rebase/pull ... Plouf plouf
ou encore les remote tracking ou pas, les staging area dont on se sert une fois tous les 15 ans alors qu'on veut juste commiter, les add --all alors qu'on veut toujours tout ajouter par défaut et autres options qu'il faut toujours rajouter pour obtenir le comportement "normal".
L'option -m qu'il faut surtout pas oublier pour pas qu'il poireaute 2h avant de t'ouvrir un ugly vim par défaut.
L'usine à gaz qu'il faut monter pour partager son repo en http lorsqu'on veut pas utiliser le protocole natif
Le packing régulier sous peine de voir la taille de son repo exploser.
Vive l'usine à gaz
Les hooks qui passent leur temps à forker des process au lieu de prévoir des appels de fonction dans des processus legers (Vive python)
Les supers perfs qui font qu'il faille 10 mn pour "cloner" un repo de 8 Mo parce qu'il s'amuse à examiner/compresser les objets un par un au lieu d'envoyer tout d'un bloc (ben ouais git-upload-pack sait faire que ça). Essayez le repo de jgit pour rire.
Git taillé pour les perfs ....Mouarf !
Plus je l'utilise plus j'ai l'impression qu'ils ont copié Clearcase en plus lourd et moins fini.
Hg au moins ca marche out of the box vite et bien.
J'espère que le kernel est moins fait à l'arrache et plus consistant mais les propos de Linus lui-même sur son embonpoint ne me rassurent pas.
[^] # Re: Sinon y'a iFolder
Posté par El Titi . En réponse à la dépêche Syncany, une alternative libre à Dropbox avec bien plus de fonctionnalités. Évalué à 5.
Ah ben moi je préfère largement un hg branch et un hg resolve
Je vois pas où est le pb ?
Ca comparé à un git fetch/update/rebase/pull ... Plouf plouf
ou encore les remote tracking ou pas, les staging area dont on se sert une fois tous les 15 ans alors qu'on veut juste commiter, les add --all alors qu'on veut toujours tout ajouter par défaut et autres options qu'il faut toujours rajouter pour obtenir le comportement "normal".
L'option -m qu'il faut surtout pas oublier pour pas qu'il poireaute 2h avant de t'ouvrir un ugly vim par défaut.
L'usine à gaz qu'il faut monter pour partager son repo en http lorsqu'on veut pas utiliser le protocole natif
Le packing régulier sous peine de voir la taille de son repo exploser.
Vive l'usine à gaz
Les hooks qui passent leur temps à forker des process au lieu de prévoir des appels de fonction dans des processus legers (Vive python)
Les supers perfs qui font qu'il faille 10 mn pour "cloner" un repo de 8 Mo parce qu'il s'amuse à examiner/compresser les objets un par un au lieu d'envoyer tout d'un bloc (ben ouais git-upload-pack sait faire que ça). Essayez le repo de jgit pour rire.
Git taillé pour les perfs ....Mouarf !
Plus je l'utilise plus j'ai l'impression qu'ils ont copié Clearcase en plus lourd et moins fini.
Hg au moins ca marche out of the box vite et bien.
J'espère que le kernel est moins fait à l'arrache et plus consistant mais les propos de Linus lui-même sur son embonpoint ne me rassurent pas.
T'es sûr pour Vendredi ?