Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.
Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.
La mémoire des merge vient avec la nouvelle version de SVN (encore en bêta mais parfaitement utilisable.) http://blogs.open.collab.net/svn/2007/05/the_subversion__1.h(...)
Cette fonctionnalité attendue le hisse la hauteur des meilleurs DVCS sur ce point et il n'est guère étonnant que les DVCS étaient plus avancés sur ce point car on ne peut pas travailler sans les branches avec eux, même sur de petits projets
Gageons qu'avec cette avancée des plugins du type de celui que tu cite ne tarderons pas à venir.
Mais si tu penses que tout est pour le mieux dans le monde merveilleux des merges pour les DVCS, je t'invite à te rendre sur ce wiki très intéressant qui relate tous les approches pour merger au mieux dans les DVCS et visiblement la "silver bullet" n'existe pas. http://revctrl.org/CategoryMergeAlgorithm
Le mieux est donc encore de s'isoler le moins possible en intégrant au plus tôt les modifs pour ne pas tomber dans des cas tordus. Ce à quoi n'incite pas les DVCS
Ah et autre chose Clearcase dispose de la mémoire de merge depuis longtemps et dans sa version UCM te permet de consulter l'historique des merge au niveau de l'arborescence (projet en entier) et du fichier.
Bref ce n'est pas une spécificité des DVCS
Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.
Et sous windows aussi ?
Un truc qui a été nativement conçu pour ne cibler qu'une seule plateforme, j'ai du mal à le croire
Vraiment, les seuls avantages d'un DVCS sont les suivants:
- Pas besoin d'administration (ouvrir un accès) ni d'en passer par un diff /patch pour un contributeur occasionnel (un pull de sa branche et c'est parti). Ca limite le scope au monde du libre. Le monde de l'entreprise a de toute façon besoin de contrôler les accès.
- Possibilité d'historiser plusieurs versions en local. Avec SVN on peut de toute façon travailler en déconnecté et à peu de frais, on peut monter un petit repository en local et scripter des commits successifs dans une sous-branche sur le serveur. En général il n'est pas bon de travailler isolé trop longtemps de toute façon car les merges sont plus délicats.
Et si vraiment ca te manque tant que ça tu as svk http://svk.elixus.org/view/HomePage
En regard de la complexité dans la gestion des branches ca me parait mince comme avantages
[^] # Re: Re:
Posté par Bozo_le_clown . En réponse au journal Git ou Mercurial ?. Évalué à 2.
Et pour le merge, tu fais comment avec SVN ?
Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.
Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.
La mémoire des merge vient avec la nouvelle version de SVN (encore en bêta mais parfaitement utilisable.)
http://blogs.open.collab.net/svn/2007/05/the_subversion__1.h(...)
Cette fonctionnalité attendue le hisse la hauteur des meilleurs DVCS sur ce point et il n'est guère étonnant que les DVCS étaient plus avancés sur ce point car on ne peut pas travailler sans les branches avec eux, même sur de petits projets
Gageons qu'avec cette avancée des plugins du type de celui que tu cite ne tarderons pas à venir.
Mais si tu penses que tout est pour le mieux dans le monde merveilleux des merges pour les DVCS, je t'invite à te rendre sur ce wiki très intéressant qui relate tous les approches pour merger au mieux dans les DVCS et visiblement la "silver bullet" n'existe pas.
http://revctrl.org/CategoryMergeAlgorithm
Le mieux est donc encore de s'isoler le moins possible en intégrant au plus tôt les modifs pour ne pas tomber dans des cas tordus. Ce à quoi n'incite pas les DVCS
Ah et autre chose Clearcase dispose de la mémoire de merge depuis longtemps et dans sa version UCM te permet de consulter l'historique des merge au niveau de l'arborescence (projet en entier) et du fichier.
Bref ce n'est pas une spécificité des DVCS
Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.
Et sous windows aussi ?
Un truc qui a été nativement conçu pour ne cibler qu'une seule plateforme, j'ai du mal à le croire
Vraiment, les seuls avantages d'un DVCS sont les suivants:
- Pas besoin d'administration (ouvrir un accès) ni d'en passer par un diff /patch pour un contributeur occasionnel (un pull de sa branche et c'est parti). Ca limite le scope au monde du libre. Le monde de l'entreprise a de toute façon besoin de contrôler les accès.
- Possibilité d'historiser plusieurs versions en local. Avec SVN on peut de toute façon travailler en déconnecté et à peu de frais, on peut monter un petit repository en local et scripter des commits successifs dans une sous-branche sur le serveur. En général il n'est pas bon de travailler isolé trop longtemps de toute façon car les merges sont plus délicats.
Et si vraiment ca te manque tant que ça tu as svk
http://svk.elixus.org/view/HomePage
En regard de la complexité dans la gestion des branches ca me parait mince comme avantages