En fait il faut faire la différence entre l'extraction en vue d'une édition (checkout) et la reservation d'un jeton d'exclusivité.
Pour certains outils (Clearcase, Perforce -jesaisapsaipalibre), les fichiers que l'on récupère dans son repertoire de travail sont tous en lecture seule. Pour editer un fichier, il est nécessaire de l'extraire en ecriture explicitement ('cleartool co' ou 'p4 edit'). On a donc un accès au serveur qui permet de tracer les accès au fichiers.
L'intêret est donc plus pour le chef de projet qui peut gérer plus finement la répartition des changements et leur livraisons.Les outils de bug tracking disposent alors de plus d'informations et la gestion de projet est plus précise. (cf. Perforce)
L'autre avantage est qu'on peut réassocier une modifcation déjà effectuée sur un fichier à un autre changement plutôt qu'en faire une copie et effacer les modifications (svn revert)
Lors de l'extraction, il est aussi possible d'obtenir un jeton d'exclusivité sur le fichier que l'on veut editer, ce qui permet d'eviter qu'un autre n'edite le même fichier que toi.(interessant pour certains types de fichiers uniquement).
Par défaut avec des outils comme CVS et SVN, le bloquage se fait au moment de la remise (commit).
On n'est pas prévenu qu'un objet est déjà édité, car on a déjà les droits d'écriture dessus. Il faut donc prendre l'initiative de consulter le serveur pour vérifier que personne ne l'a edité. De même, il est necessaire que chacun s'astreigne à réserver le fichier avant modification, et il est facile d'oublier.(SVN permet de forcer la politique précédente)
Un autre intêret du lock concerne le commit.
, lorsqu'on travaille sur un changement qui concerne de nombreux fichiers:
Au moment de comitter, il se trouve qu'un ficher que l'on a modifié, a déjà été remis. On merge donc les différences, on reteste et paf!!! un autre fichier a été remis entre temps. On risque de merger ad vitam eternam sans jamais pouvoir remettre son changement.
Le solution: verrouiller tous les fichiers que l'on a édité afin d'empêcher les autres de comitter, le temps que l'on ait résolu les conflits de merges.
L'outil idéal est donc celui qui permet de définir sa politique de concurrence d'accès.
1/ Fichier en ecriture et résoulution des conflits au meoment du commit
2/ Fichiers en lecture seule, action d'éditer le fichier afin de tracer les changements et résolution des conflits au moment du commit
3/ Fichiers en lecture seule et possibilité de le réserver en exclusivité
4/ Possibilté de réserver le fichier pour être prioritire sur la remise
5/ Bien entendu, il doit être possible de forcer les verrous
En conclusion: ces politiques centralisées correspondent mieux à des besoins entreprises qu'à des developpements OpenSource.
Avec des outils distribués il me parait beaucoup plus délicat de mettre en place une administration centralisée de ce type (lock inter-repository).SVN me semble plus complet sur ces attentes.
[^] # Re: Verrouillage
Posté par golum . En réponse à la dépêche Subversion 1.2. Évalué à 3.
Pour certains outils (Clearcase, Perforce -jesaisapsaipalibre), les fichiers que l'on récupère dans son repertoire de travail sont tous en lecture seule. Pour editer un fichier, il est nécessaire de l'extraire en ecriture explicitement ('cleartool co' ou 'p4 edit'). On a donc un accès au serveur qui permet de tracer les accès au fichiers.
L'intêret est donc plus pour le chef de projet qui peut gérer plus finement la répartition des changements et leur livraisons.Les outils de bug tracking disposent alors de plus d'informations et la gestion de projet est plus précise. (cf. Perforce)
L'autre avantage est qu'on peut réassocier une modifcation déjà effectuée sur un fichier à un autre changement plutôt qu'en faire une copie et effacer les modifications (svn revert)
Lors de l'extraction, il est aussi possible d'obtenir un jeton d'exclusivité sur le fichier que l'on veut editer, ce qui permet d'eviter qu'un autre n'edite le même fichier que toi.(interessant pour certains types de fichiers uniquement).
Par défaut avec des outils comme CVS et SVN, le bloquage se fait au moment de la remise (commit).
On n'est pas prévenu qu'un objet est déjà édité, car on a déjà les droits d'écriture dessus. Il faut donc prendre l'initiative de consulter le serveur pour vérifier que personne ne l'a edité. De même, il est necessaire que chacun s'astreigne à réserver le fichier avant modification, et il est facile d'oublier.(SVN permet de forcer la politique précédente)
Un autre intêret du lock concerne le commit.
, lorsqu'on travaille sur un changement qui concerne de nombreux fichiers:
Au moment de comitter, il se trouve qu'un ficher que l'on a modifié, a déjà été remis. On merge donc les différences, on reteste et paf!!! un autre fichier a été remis entre temps. On risque de merger ad vitam eternam sans jamais pouvoir remettre son changement.
Le solution: verrouiller tous les fichiers que l'on a édité afin d'empêcher les autres de comitter, le temps que l'on ait résolu les conflits de merges.
L'outil idéal est donc celui qui permet de définir sa politique de concurrence d'accès.
1/ Fichier en ecriture et résoulution des conflits au meoment du commit
2/ Fichiers en lecture seule, action d'éditer le fichier afin de tracer les changements et résolution des conflits au moment du commit
3/ Fichiers en lecture seule et possibilité de le réserver en exclusivité
4/ Possibilté de réserver le fichier pour être prioritire sur la remise
5/ Bien entendu, il doit être possible de forcer les verrous
Je ne sais pas comment se comporte SVN 1.2 mais j'ai cru comprendre qu'il était possible de mettre en place toutes les politiques sauf la 2 au moyen des hooks
http://svn.collab.net/repos/svn/trunk/notes/locking/locking-functio(...)
Il faudra que teste pour en être sûr.
En conclusion: ces politiques centralisées correspondent mieux à des besoins entreprises qu'à des developpements OpenSource.
Avec des outils distribués il me parait beaucoup plus délicat de mettre en place une administration centralisée de ce type (lock inter-repository).SVN me semble plus complet sur ces attentes.