> Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au
> mainteneur est pour moi une manière de faire très peu en adéquation avec un
> développement ouvert.
Tu proposes quoi comme alternative avec un VCS centralisé ? J'en vois deux :
1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
Pour la version 1), je ne sais pas si ça t'es déjà arrivé d'être autorisé à commiter sur le SVN d'un projet avant d'avoir fait tes preuves avec du code, mais perso, ça ne m'est jamais arrivé, même en rêve. Maintenant, admettons que ça arrive. Cool, je peux commiter sur le dépôt, je n'ai même pas besoin de parler du code sur la mailing-list avant de commiter. C'est plutôt un handicap pour le côté communautaire, non, de pouvoir commiter sans discuter ?
Reste la solution 2), et c'est justement là qu'un DVCS est infiniment plus puissant/pratique, puisque tu peux faire tes commits en local, donc gérer assez facilement plusieurs patchs (y compris si les patchs dépendent les uns des autres).
Le fait qu'on puisse cloner un dépôt est justement quelque chose qui force un fonctionnement communautaire. Avec un VCS centralisé, tu as en général une short-list de gens qui ont les droits pour les commits, et le fait que techniquement ils aient ce droit leur donne un très grand pouvoir de décision. Les gens qui ne sont pas sur la short-list sont mis à l'écart. Avec un DVCS, tu peux aussi avoir un petit nombre de gens qui ont accès au dépôt de référence (éventuellement, ce petit nombre peut être 1), mais si ils abusent de leur pouvoir, les autres contributeurs peuvent continuer à travailler et à s'organiser. Un corolaire est que les mainteneurs n'abusent pas de leurs pouvoir pour les projets gérés par un DVCS.
> Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web
> (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un
> développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et
> l'abandonne au bon vouloir.
Quelle différence avec un SVN accessible en lecture seule, publié et abandonné au bon vouloir ?
# workflows
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git malgré moi. Évalué à 3.
> mainteneur est pour moi une manière de faire très peu en adéquation avec un
> développement ouvert.
Tu proposes quoi comme alternative avec un VCS centralisé ? J'en vois deux :
1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
Pour la version 1), je ne sais pas si ça t'es déjà arrivé d'être autorisé à commiter sur le SVN d'un projet avant d'avoir fait tes preuves avec du code, mais perso, ça ne m'est jamais arrivé, même en rêve. Maintenant, admettons que ça arrive. Cool, je peux commiter sur le dépôt, je n'ai même pas besoin de parler du code sur la mailing-list avant de commiter. C'est plutôt un handicap pour le côté communautaire, non, de pouvoir commiter sans discuter ?
Reste la solution 2), et c'est justement là qu'un DVCS est infiniment plus puissant/pratique, puisque tu peux faire tes commits en local, donc gérer assez facilement plusieurs patchs (y compris si les patchs dépendent les uns des autres).
Le fait qu'on puisse cloner un dépôt est justement quelque chose qui force un fonctionnement communautaire. Avec un VCS centralisé, tu as en général une short-list de gens qui ont les droits pour les commits, et le fait que techniquement ils aient ce droit leur donne un très grand pouvoir de décision. Les gens qui ne sont pas sur la short-list sont mis à l'écart. Avec un DVCS, tu peux aussi avoir un petit nombre de gens qui ont accès au dépôt de référence (éventuellement, ce petit nombre peut être 1), mais si ils abusent de leur pouvoir, les autres contributeurs peuvent continuer à travailler et à s'organiser. Un corolaire est que les mainteneurs n'abusent pas de leurs pouvoir pour les projets gérés par un DVCS.
> Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web
> (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un
> développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et
> l'abandonne au bon vouloir.
Quelle différence avec un SVN accessible en lecture seule, publié et abandonné au bon vouloir ?