Le 17/05/2013 18:30, Jérémie Courrèges-Anglas a écrit :
Wallace wallace@morkitu.org writes:
[...]
A voir de toute façon il faudra bien que j'y passe pour remplacer subversion qui est de plus en plus abandonné, l'informatique évolue et il faut suivre les tendances c'est comme ça.
Y'a des tendances qui ont la vie dure. La plupart de mes collègues encore étudiants ou fraîchement diplômés n'ont utilisé que svn, soit de leur propre chef, soit parce que c'est le seul vcs qu'on les a forcé à utiliser dans leurs formations (et encore, ça c'est quand ils en ont vu un).
J'avais appris csv en 2000 c'était déjà pas mal de migrer sur subversion le gap de fonctionnalité me suffisait en fait :) Va falloir se remettre en question (même si c'est proche). C'est vrai que le côté centralisé rassure en fait, le côté éclaté (même si je sais que cela marche) me laisse l'idée que potentiellement un boulot peut être sur un ordi qui va crasher son disque quand son backup est pas synchro ou qu'il n'y en a pas. J'ai dans ma vie en tant que salarié avant d'être patron jamais vu de sauvegarde de poste des employés. Ca aide pas à vouloir proposer un repo décentralisé.
D'un autre côté svn n'est pas mort au niveau développement, la version 1.8 sort (normalement) dans un mois et y'a une -rc2 dispo.
Oui c'est vrai mais l'effet de mode et l'utilisation en masse va faire que git va prendre le dessus. SVN est utilisé en entreprise car ils migrent pas de dépôt tous les 4 matins. Il faut donc bien le faire évoluer pour qu'il colle aux distros modernes et corrige des bugs.
Par contre si vous avez des urls à passer sur une exploitation de git centralisé ou même des retours d'expériences ça m'intéresse de voir comment ça fonctionne dans la logique.
Pas au niveau "pro", mais chez Faimaison[1] on utilise Git conjointement à gitolite, dans une architecture centralisée donc. Ça va de l'utilisateur avancé qui va utiliser des branches locales et remote, à d'autres qui ne travaillent que sur la branche master.
Au niveau gitolite, quelques éléments à propos de notre utilisation :
- pas besoin de compte unix par utilisateur, un seul compte utilisé uniquement par gitolite
- groupes d'utilisateurs (pour déterminer qui accède à quel dépôt ; la granularité peut descendre au niveau des tags et / ou des branches.
- clés SSH multiples pour certains utilisateurs
- réplication 1 master -> 2 slave :
- un push sur un slave redirige de manière transparente sur le master
- si le master tombe on a toujours accès en lecture sur les slave ; un changement dans la conf gitoite + entrée dns et les utilisateurs ne voient (presque rien)
- hooks pour des mails automatiques (non spécifique gitolite)
- on envisage aussi d'utiliser ces hooks pour déployer automatiquement (site web, etc - non spécifique gitolite)
- on utilise des versions stables de gitolite, directement depuis l'upstream, pour parer à d'éventuelles incompatibilités entre les versions de gitolite packagées sur les distros supports.
C'est pas grand chose, mais ça va déjà plus loin que ce que j'ai pu voir jusqu'à présent dans un contexte "pro" avec du svn.
Intéressant, le coup du compte ssh unique me soulage car il me semble avoir vu que des implémentations avec compte / user ce qui peu être long à gérer à force. La réplication par contre faut que je regarde ce qu'on peut faire, je n'étais pas encore arrivé à ce niveau là dans la réflexion. Une VPS bien sauvegardée capable d'être restaurée intégralement rapidement c'est pas mal aussi dans un premier temps.