La différence c'est que Perforce supporte intrinséquement la notion de demande de changement. Tu peux même affecter un fichier que tu es en train d'editer à une autre demande.
Ce genre d'intégration est assez courante avec des logiciels proprio
(Perforce, ClearcQuest/UCM Clearcase)
Le gros avantage c'est que la gestion des demandes changements est centralisée.
La demande doit exister avant que tu ne puisses modifier un changement. Cette demande est créée en genéral par le chef de projet qui a fait un travail de classement préalable(bug, feature request, enhancement, refusée, ...)
Le développeur se voit affecté une liste de demande ou consulte la liste complète et en choisit une.
L'intégration avec l'outil de version fait que 2 developpeurs ne prendront pas en charge la même demande et ne se marcheront pas sur les pieds, ce qui n'est pas le cas avec les gestionnaires classiques
(si le developpeur oublie de consulter le bugzilla, rien ne l'empêche de modifier les fichiers pour un changement déjà pris en compte alors qu'il est obligé de consulter dans l'uatre cas ou de créer un changement doublons qu'un petit copain ne manquera pas de lui rappeler)
Pour plus de souplesse l'outil doit accepter que le développeur puisse se créer une demande de changement (demande oubliée, décomposition d'une changement, ...) mais ca reste une politique à définir.
Enfin, il faut bien noter que plusieurs changements peuvent concerner les même fichiers donc l'exclusivité sur un changement n'implique pas un jeton d'exclusivité sur un fichier.
Je n'ai pas regardé comment fonctionne l'intégration trac/SVN mais je pense qu'il faudrait modifier SVN pour obtenir les mêmes fonctionnalités (on pourrait s'appuyer sur les properties mais qu'il faut implementer la gestion de l'exclusivité sur le changement)
[^] # Re: PDTI
Posté par golum . En réponse au journal Gestionnaire de sources et bugtracker. Évalué à 2.
Ce genre d'intégration est assez courante avec des logiciels proprio
(Perforce, ClearcQuest/UCM Clearcase)
Le gros avantage c'est que la gestion des demandes changements est centralisée.
La demande doit exister avant que tu ne puisses modifier un changement. Cette demande est créée en genéral par le chef de projet qui a fait un travail de classement préalable(bug, feature request, enhancement, refusée, ...)
Le développeur se voit affecté une liste de demande ou consulte la liste complète et en choisit une.
L'intégration avec l'outil de version fait que 2 developpeurs ne prendront pas en charge la même demande et ne se marcheront pas sur les pieds, ce qui n'est pas le cas avec les gestionnaires classiques
(si le developpeur oublie de consulter le bugzilla, rien ne l'empêche de modifier les fichiers pour un changement déjà pris en compte alors qu'il est obligé de consulter dans l'uatre cas ou de créer un changement doublons qu'un petit copain ne manquera pas de lui rappeler)
Pour plus de souplesse l'outil doit accepter que le développeur puisse se créer une demande de changement (demande oubliée, décomposition d'une changement, ...) mais ca reste une politique à définir.
Enfin, il faut bien noter que plusieurs changements peuvent concerner les même fichiers donc l'exclusivité sur un changement n'implique pas un jeton d'exclusivité sur un fichier.
Je n'ai pas regardé comment fonctionne l'intégration trac/SVN mais je pense qu'il faudrait modifier SVN pour obtenir les mêmes fonctionnalités (on pourrait s'appuyer sur les properties mais qu'il faut implementer la gestion de l'exclusivité sur le changement)