- je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier
SVN résout ce problème complètement:
Se prémunir que 2 personnes accèdent concurremment à une ressource.CQFD
Nul n'est à l'abri d'un oubli.
Que des questions d'organisation subsistent peut -être mais c'est décorrélé du pb qui nous préoccupe.
J'aurais préferé que tu nous répondes sur la façon dont tu gérerais ce pb alors je t'aide un peu.
1- isoler lorsque c'est possible les fichiers dans une même arborescence (specs, fichier UML) et utiliser une branche partagée lorsque l'outil support le modèle centralisé.
2- pour les autres fichiers, déployer des hooks sur chacun de postes (avec le problématiques qui s'ensuivent , portage, droits, ...). Le hook accédera à un serveur central pour gérer l'exclusivité. (Réinventons la roue )
Dommage que pour des considérations de securité certains DVCS (hg, git je sias pas) choisissent délibérément de ne pas propager les hooks, du coup c'est aux admins de s'en charger.
Ou mieux il pourrait prendre en charge ce ca en natif aavec ses prtopres métadonnées (flag particulier sur un fichier qui indique qu'on doit réserver un fichier sur une archive particulière, debranchable en locaal si nécessaire )
En même temps pour quelqu'un qui travaille en mode deconnecté 6 mois durant je comprend que ca ne serve pas. Autant modifier toutes les specs a gogo et tout refaire après. Pas la peine d'implementer ce use case dans un DVCS pour les rares fois où on en a besoin.
perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.
A vi vos espaces de travail sont sur des disques réseaux backupés.
Ca aide vachement à travailler en mode deconnecté ca. Il me semblait que c'était l'argument massue en faveur des DVCS.
La seule solution est de déployer une solution de sauvegarde automatique à la connexion, ce qui est techniquement plus complexe et nécessite une bonne organisation derrière
Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).
SVN n'empêche pas non plus de travailler sur de branches parallèles et de confier les merges à une équipe d'intégration qui est chargée d'approuver de ou de rejeter les modification su les branches maître.
Le modèle user/team centric est parfaitement applicable
[^] # Re: Re:
Posté par Bozo_le_clown . En réponse au journal Git ou Mercurial ?. Évalué à 1.
- je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier
SVN résout ce problème complètement:
Se prémunir que 2 personnes accèdent concurremment à une ressource.CQFD
Nul n'est à l'abri d'un oubli.
Que des questions d'organisation subsistent peut -être mais c'est décorrélé du pb qui nous préoccupe.
J'aurais préferé que tu nous répondes sur la façon dont tu gérerais ce pb alors je t'aide un peu.
1- isoler lorsque c'est possible les fichiers dans une même arborescence (specs, fichier UML) et utiliser une branche partagée lorsque l'outil support le modèle centralisé.
2- pour les autres fichiers, déployer des hooks sur chacun de postes (avec le problématiques qui s'ensuivent , portage, droits, ...). Le hook accédera à un serveur central pour gérer l'exclusivité. (Réinventons la roue )
Dommage que pour des considérations de securité certains DVCS (hg, git je sias pas) choisissent délibérément de ne pas propager les hooks, du coup c'est aux admins de s'en charger.
Ou mieux il pourrait prendre en charge ce ca en natif aavec ses prtopres métadonnées (flag particulier sur un fichier qui indique qu'on doit réserver un fichier sur une archive particulière, debranchable en locaal si nécessaire )
En même temps pour quelqu'un qui travaille en mode deconnecté 6 mois durant je comprend que ca ne serve pas. Autant modifier toutes les specs a gogo et tout refaire après. Pas la peine d'implementer ce use case dans un DVCS pour les rares fois où on en a besoin.
perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.
A vi vos espaces de travail sont sur des disques réseaux backupés.
Ca aide vachement à travailler en mode deconnecté ca. Il me semblait que c'était l'argument massue en faveur des DVCS.
La seule solution est de déployer une solution de sauvegarde automatique à la connexion, ce qui est techniquement plus complexe et nécessite une bonne organisation derrière
Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).
SVN n'empêche pas non plus de travailler sur de branches parallèles et de confier les merges à une équipe d'intégration qui est chargée d'approuver de ou de rejeter les modification su les branches maître.
Le modèle user/team centric est parfaitement applicable