hum ... jsuis pas vraiment d'accord, surtout avec le dernier paragraphe (ou plutôt je ne réagis pas du tout pareil)
Moi ce qui m'intéresse aujourd'hui dans un truc comme git (s'il y a autre chose de mieux ça me gène pas hein ;)) c'est justement pas l'aspect décentralisé (même si c'est pratique) mais l'aspect branches.
Aujourd'hui, je dois me préparer à maintenir un trunk, 2 à 3 branches de maintenance, 1, 2 ou plus ça dépend branches de dev expérimental / choses ne rentrant pas dans le trunk par projet. (c'est du grossier)
avec un truc comme ça et un système comme svn c'est galère.
Alors oui c'est technique, mais ça pue.
Dans certains cas il est interdit à certaines personnes de commiter sur des branches de maintenance. Problème : certaines personnes vont tout de même créer des correctifs mais ne pourront jamais les versionner -> c'est le bordel, les commits ne ressemblent plus à rien, c'est chiant à faire, et s'ils sont pas intégrés rapidement c'est horrible.
Avec un système de branche ... c'est plus facile.
Le côté décentralisé ... ben heu ... c'est pas ce que je recherche, mais ça peu avoir des côtés intéressant, surtout lorsque l'un des développeurs veut se lancer dans une expérimentation sans polluer la branche principale, ni créer de branche distante sur le répo principal.
De puis, pour mon cas, ça reste une utilisation assez professionnelle et dans ce cas c'est pas l'outil qui pose des problèmes de communication, loin de là.
D'ailleurs un tel outil permet dans certains cas de mieux communiquer :
plutôt que de se retrouver un jour avec des commits apparaissant n'importe comment sans avertir les développeurs en charge, on va au contraire apprendre qu'untel a fait des modifs dans sa branche / nous a envoyé des patch et on va les intégrer.
Alors oui, gestion des droits, toussa, mais ça ne répond pas toujours aux règles fines qu'on souhaite.
(je sais pas si je me fais bien comprendre là...)
Un VCS décentralisé ne favorise pas plus le travail individuel, mais il garanti à chacun de pouvoir versionner son taff (très important, surtout quand on voit que certains ne comprenent toujours pas l'intéret...) à chacun de pouvoir améliorer le taff de l'autre, et aux responsables de pouvoir améliorer l'ensemble en prenant facilement les idées de tous.
Ca fait un peu fouilli dit comme ça mais c'est au contraire poser un cadre, des outils pour le réguler facilement.
> Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
C'est une erreur je pense, git est simplement un meilleur outil que svn. Il manque beaucoup trop de feature, et le fait d'ajouter des commits locaux ... voui mais tant que le merge ne sera pas utilisable franchement j'en veux pas.
Et les features ... ben c'est aujourd'hui que j'en ai besoin :(
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 6.
Moi ce qui m'intéresse aujourd'hui dans un truc comme git (s'il y a autre chose de mieux ça me gène pas hein ;)) c'est justement pas l'aspect décentralisé (même si c'est pratique) mais l'aspect branches.
Aujourd'hui, je dois me préparer à maintenir un trunk, 2 à 3 branches de maintenance, 1, 2 ou plus ça dépend branches de dev expérimental / choses ne rentrant pas dans le trunk par projet. (c'est du grossier)
avec un truc comme ça et un système comme svn c'est galère.
Alors oui c'est technique, mais ça pue.
Dans certains cas il est interdit à certaines personnes de commiter sur des branches de maintenance. Problème : certaines personnes vont tout de même créer des correctifs mais ne pourront jamais les versionner -> c'est le bordel, les commits ne ressemblent plus à rien, c'est chiant à faire, et s'ils sont pas intégrés rapidement c'est horrible.
Avec un système de branche ... c'est plus facile.
Le côté décentralisé ... ben heu ... c'est pas ce que je recherche, mais ça peu avoir des côtés intéressant, surtout lorsque l'un des développeurs veut se lancer dans une expérimentation sans polluer la branche principale, ni créer de branche distante sur le répo principal.
De puis, pour mon cas, ça reste une utilisation assez professionnelle et dans ce cas c'est pas l'outil qui pose des problèmes de communication, loin de là.
D'ailleurs un tel outil permet dans certains cas de mieux communiquer :
plutôt que de se retrouver un jour avec des commits apparaissant n'importe comment sans avertir les développeurs en charge, on va au contraire apprendre qu'untel a fait des modifs dans sa branche / nous a envoyé des patch et on va les intégrer.
Alors oui, gestion des droits, toussa, mais ça ne répond pas toujours aux règles fines qu'on souhaite.
(je sais pas si je me fais bien comprendre là...)
Un VCS décentralisé ne favorise pas plus le travail individuel, mais il garanti à chacun de pouvoir versionner son taff (très important, surtout quand on voit que certains ne comprenent toujours pas l'intéret...) à chacun de pouvoir améliorer le taff de l'autre, et aux responsables de pouvoir améliorer l'ensemble en prenant facilement les idées de tous.
Ca fait un peu fouilli dit comme ça mais c'est au contraire poser un cadre, des outils pour le réguler facilement.
> Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
C'est une erreur je pense, git est simplement un meilleur outil que svn. Il manque beaucoup trop de feature, et le fait d'ajouter des commits locaux ... voui mais tant que le merge ne sera pas utilisable franchement j'en veux pas.
Et les features ... ben c'est aujourd'hui que j'en ai besoin :(