Yep, tout juste.
Le plugin en question doit etre hgeclipse ou un truc du genre.
C'est pas complique, ya 2 plugin hg pour eclipse, un pourri, abandonne, et l'autre qui marche.
Mon utilisation: on utilise perforce au taff, et j'aime pas du tout. Du coup je clone les repo sur lesquels je bosse localement, je bosse contre mon mercurial et je pousse le soir vers p4.
Je branche de temps a autres, genre quand j'ai un gros refactoring/clean up a faire "under the radar" sur un projet ecrit avec les pieds, ca me permet de bosser sur les deux a la fois, ensuite je merge le tout et, paf, le projet nettoye.
Leplugin fait a peu pres tout ce que tu veux qu'il fasse. Le tout integre a la team perspective.
Push pull commit merge diff, pour le basique, evidemment.
Historique par fichier, switch vers une aute branch, tag, bookrmark, revision. Update vers ce que tu veux, tu peux brancher et meme faire un hg serve. Ca a l'air de supporter des extensions, mais je peux pas t'en dire plus, jamais utilise.
Leur organisation des repos est pas la plus facile a utiliser, mais ca reste tres raisonnable. Ils ont une vue hierarchique des repos qui a un interet certain.
La raison pour laquelle il parait poussif est simplement parce que c'est un plugin eclipse, d'une part (ca reagit aussi vite que subclipse), en comparaison a machg, ca parait lent. Disons que les qq secondes de lag sont acceptables quand tu fais 2 commits par jour avec svn, pas quand t'en fait 15 avec un dvcs.
L'autre raison est lie a mon utilisation. On utilise maven, je dois avoir qq chose comme 25 ou 30 projets dans mon workspace, la plupart sont fermes en general (m2eclipse est assez lent, plus encore que maven tout court), du coup je ferme tout la plupart du temps.
Et projet ferme = pas de support hg avant que t'ouvres le projet. Et ouvrir un projet, c'est lent, bien plus que de fair cmd tab et passer dans machg.
Une autre raison aussi, c'est que l'organisation en projet d'eclipse de projets maven colle pas trop. En gros, un projet maven avec 4 modules va te donner 4 projet, qui vont pas forcement apparaitre comme etant etre dans le meme repo.
Disons que si t'as 2 projet mvn, venant de 2 repos different, avec chacun 3 modules, tu vas avoir 6 projets, et t'auras aucune idee de quoi vient d'ou. Les workings set permettent de mitiger ca, mais ca montre tres vite ses limites.
Ca c'est plus un probleme d'eclipse qu'autre chose cela dit, t'auras le meme pb svec git, svn ou cpold.
Le gros probleme d'egit, c'est surtout qu'il est en pre alpha 0.1.
Pas de support de diff pour un plugin pareil, c'est vraiment redhibitoire, les mecs sont cense bosser dessus cela dit.
On a aussi envisage des dvcs au taff recemment, on a fini par laisser tomber (d'autres chats, plus gros, a fouetter avant), mais ce qu'il en est ressorti:
- les boss ont dit "on veut git" parceque ce sont des geeks cli hardcore
- on a aussi zieute hg
- on s'est rendu compte que le support hg dans le tooling est aussi bon
- on a bien vu que git est tres dur a utiliser, et que ca peut etre un gros probleme de former tout le monde
- niveau features, hg et git se valent largement pour une boite ou tout le monde est dans le meme batiment.
- on est un java shop, donc pas de support eclipse = thanks, but no thanks
- hg est beaucoup plus simple, vraiment, plus propre, donc si la migration se fait, elle se fera vers mercurial.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: hg
Posté par pasScott pasForstall . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 0.
Le plugin en question doit etre hgeclipse ou un truc du genre.
C'est pas complique, ya 2 plugin hg pour eclipse, un pourri, abandonne, et l'autre qui marche.
Mon utilisation: on utilise perforce au taff, et j'aime pas du tout. Du coup je clone les repo sur lesquels je bosse localement, je bosse contre mon mercurial et je pousse le soir vers p4.
Je branche de temps a autres, genre quand j'ai un gros refactoring/clean up a faire "under the radar" sur un projet ecrit avec les pieds, ca me permet de bosser sur les deux a la fois, ensuite je merge le tout et, paf, le projet nettoye.
Leplugin fait a peu pres tout ce que tu veux qu'il fasse. Le tout integre a la team perspective.
Push pull commit merge diff, pour le basique, evidemment.
Historique par fichier, switch vers une aute branch, tag, bookrmark, revision. Update vers ce que tu veux, tu peux brancher et meme faire un hg serve. Ca a l'air de supporter des extensions, mais je peux pas t'en dire plus, jamais utilise.
Leur organisation des repos est pas la plus facile a utiliser, mais ca reste tres raisonnable. Ils ont une vue hierarchique des repos qui a un interet certain.
La raison pour laquelle il parait poussif est simplement parce que c'est un plugin eclipse, d'une part (ca reagit aussi vite que subclipse), en comparaison a machg, ca parait lent. Disons que les qq secondes de lag sont acceptables quand tu fais 2 commits par jour avec svn, pas quand t'en fait 15 avec un dvcs.
L'autre raison est lie a mon utilisation. On utilise maven, je dois avoir qq chose comme 25 ou 30 projets dans mon workspace, la plupart sont fermes en general (m2eclipse est assez lent, plus encore que maven tout court), du coup je ferme tout la plupart du temps.
Et projet ferme = pas de support hg avant que t'ouvres le projet. Et ouvrir un projet, c'est lent, bien plus que de fair cmd tab et passer dans machg.
Une autre raison aussi, c'est que l'organisation en projet d'eclipse de projets maven colle pas trop. En gros, un projet maven avec 4 modules va te donner 4 projet, qui vont pas forcement apparaitre comme etant etre dans le meme repo.
Disons que si t'as 2 projet mvn, venant de 2 repos different, avec chacun 3 modules, tu vas avoir 6 projets, et t'auras aucune idee de quoi vient d'ou. Les workings set permettent de mitiger ca, mais ca montre tres vite ses limites.
Ca c'est plus un probleme d'eclipse qu'autre chose cela dit, t'auras le meme pb svec git, svn ou cpold.
Le gros probleme d'egit, c'est surtout qu'il est en pre alpha 0.1.
Pas de support de diff pour un plugin pareil, c'est vraiment redhibitoire, les mecs sont cense bosser dessus cela dit.
On a aussi envisage des dvcs au taff recemment, on a fini par laisser tomber (d'autres chats, plus gros, a fouetter avant), mais ce qu'il en est ressorti:
- les boss ont dit "on veut git" parceque ce sont des geeks cli hardcore
- on a aussi zieute hg
- on s'est rendu compte que le support hg dans le tooling est aussi bon
- on a bien vu que git est tres dur a utiliser, et que ca peut etre un gros probleme de former tout le monde
- niveau features, hg et git se valent largement pour une boite ou tout le monde est dans le meme batiment.
- on est un java shop, donc pas de support eclipse = thanks, but no thanks
- hg est beaucoup plus simple, vraiment, plus propre, donc si la migration se fait, elle se fera vers mercurial.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.