J'ai l'impression que votre différence d'appréciation provient de votre perspective.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.
Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.
Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.
Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.
En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.
Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.
[^] # Re: Git malgré moi
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 3.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.
Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.
Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.
Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.
En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.
Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.
Voilà je crains avoir encore plus délayé que toi.