Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?
Ben par définition avec un outil centralisé tu stockes pas tout un repository en local donc oui faut aller récupérer sur le serveur ce qu'il te faut et juste ce qu'il te faut au moment ou tu en as besoin.
Avec ton système si tu n'as cloné que récemment le projet, tu vas déjà "explicitement" recupérer la branche de ta révision ou ta révision (qui va remonter la branche associée)dans ton archive.
Avec svn le switch ne transfère que le strict nécessaire
Bref rien de choquant.
Le seul avantage que je vois à un DVCS est l'effet proxy.
A force tu conserves en local toute les révisions que tu as récupérées. peut-être avec l'avantage du cache en moins. Il ne se vide pas automatiquement lorsqu'il devient trop volumineux.
Espérons que les DVCS sont concus pour mutualiser le stockage des archives en local parce qu'avec 50 clones de tout un projet ca va vite saturer la place.
En outre il n'est pas inconcevable (si ce n'est pas déjà le cas) de disposer de cache avec SVN si le besoin s'en fait ressentir. Perforce le fait bien et il est centralisé
git contrairement à svn est documenté par des pages man ...
Ben oui encore une preuve que cet outil est concu d'abord et avant tout pour des linuxiens pur et dur et pas prévu être multiplatforme.
Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl.
Même remarque
Un projet multiplateforme qui a vraiment besoin de l'aspect distribué a donc tout intérêt a utiliser Hg.
Le posteur du journal nous a confié qu'il bossait sur RoR donc ca devrait l'aider à prendre sa décision puisque ruby et RoR tout comme python répondent au critères de portabilité et peuvent donc concerner des devs d'horizons différents.
[^] # Re: Re:
Posté par Bozo_le_clown . En réponse au journal Git ou Mercurial ?. Évalué à 1.
Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?
Ben par définition avec un outil centralisé tu stockes pas tout un repository en local donc oui faut aller récupérer sur le serveur ce qu'il te faut et juste ce qu'il te faut au moment ou tu en as besoin.
Avec ton système si tu n'as cloné que récemment le projet, tu vas déjà "explicitement" recupérer la branche de ta révision ou ta révision (qui va remonter la branche associée)dans ton archive.
Avec svn le switch ne transfère que le strict nécessaire
Bref rien de choquant.
Le seul avantage que je vois à un DVCS est l'effet proxy.
A force tu conserves en local toute les révisions que tu as récupérées. peut-être avec l'avantage du cache en moins. Il ne se vide pas automatiquement lorsqu'il devient trop volumineux.
Espérons que les DVCS sont concus pour mutualiser le stockage des archives en local parce qu'avec 50 clones de tout un projet ca va vite saturer la place.
En outre il n'est pas inconcevable (si ce n'est pas déjà le cas) de disposer de cache avec SVN si le besoin s'en fait ressentir. Perforce le fait bien et il est centralisé
git contrairement à svn est documenté par des pages man ...
Ben oui encore une preuve que cet outil est concu d'abord et avant tout pour des linuxiens pur et dur et pas prévu être multiplatforme.
Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl.
Même remarque
Un projet multiplateforme qui a vraiment besoin de l'aspect distribué a donc tout intérêt a utiliser Hg.
Le posteur du journal nous a confié qu'il bossait sur RoR donc ca devrait l'aider à prendre sa décision puisque ruby et RoR tout comme python répondent au critères de portabilité et peuvent donc concerner des devs d'horizons différents.