Flux de travail du Review Board pour le dépôt Mercurial

Question

Dans mon entreprise, nous essayons d'ajouter des pratiques de révision de code dans notre processus de développement et, à cette fin, nous avons décidé d'utiliser Commission de révision .

Alors que Review Board devrait fonctionner sans problème pour Subversion, le flux de travail pour Mercurial semble un peu compliqué. Premièrement, il semble que seule la révision a posteriori (via post-review script) soit supportée pour ce type de repo. Deuxièmement la documentation n'est pas claire si post-review supporte réellement Mercurial(elle ne mentionne que git).

Pourriez-vous décrire votre flux de travail en détail ?

Ai-je raison de penser que ça devrait être quelque chose comme ça :

Développeur :

1. cloner le répertoire principal
2. cloner le repo des fonctionnalités à partir du repo maître local
3. hack-hack dans le repo des fonctionnalités
4. commettre dans le repo des fonctionnalités
5. d'une manière ou d'une autre, exécution de la post-revue à partir d'un repo de fonctionnalité contre le repo maître parent

Réviseur :

1. examen diff
2. si c'est OK, tirez vers le dépôt maître à partir du dépôt de fonctionnalités

Answer 1

Nous venons de commencer à utiliser Mercurial et ReviewBoard dans mon entreprise. Nous faisons quelque chose de similaire au flux de travail que vous suggérez, sauf que nous ne nous occupons généralement pas des dépôts de fonctionnalités et que nous poussons toujours vers le master plutôt que de tirer du master.

Le principal problème que vous rencontrez en utilisant ReviewBoard avec un DVCS est que vous voulez que quelqu'un révise une modification de, disons, la révision 2 à la révision 3, qui sont toutes deux dans votre dépôt local mais pas dans le maître auquel ReviewBoard a accès, par exemple parce que vous attendez toujours une révision des modifications de la révision 1 à la révision 2.

La solution de ReviewBoard à ce problème est ce qu'il appelle les "parent diffs" ; cela signifie qu'au lieu de simplement télécharger le patch que vous voulez réviser, vous devez également télécharger la différence entre la dernière version dans le repo maître et la révision parent de votre patch. Cela permet à ReviewBoard de reconstruire les fichiers d'origine pour la partie gauche de sa visionneuse de différences côte à côte.

La version actuelle de ReviewBoard ne supporte pas les diffs parents pour Mercurial, mais j'ai soumis un patch qui les fait fonctionner ; je pense que cela devrait être dans la RC3.

J'ai également corrigé l'extension ReviewBoard mentionnée dans le post précédent pour lui permettre de supporter les diffs parents. Je les rendrai disponibles dès que la RC3 sera publiée.

Answer 2

Il existe une extension pour mercurial pour ce que vous voulez faire :

http://blogma.de/projects/mercurial-reviewboard.html
http://www.selenic.com/mercurial/wiki/ReviewboardExtension

Le flux de travail que vous présentez semble facile à suivre, je pense donc que vous êtes sur la bonne voie. La façon dont les services DVCS (c'est-à-dire bitbucket ou github) gèrent cela est en fait la même :

commiteur :
les étapes 1...4 sont les mêmes
5. Envoyez une demande de retrait au responsable (c'est là que votre revue de code entre en jeu).

réviseur :
1. examine la demande de pull
2. tirettes

Étant donné que cette approche fonctionne parfaitement pour les services susmentionnés, je pense qu'elle ne devrait pas vous poser de problèmes.

Answer 3

Je ne connais pas la taille de votre équipe, mais les post-reviews deviennent rapidement ingérables, surtout dans les grandes équipes, les projets critiques pour la sécurité et lorsque les réviseurs sont occupés.

GitHub et Bitbucket résolvent ce problème grâce à une approche qui n'était pas viable à l'époque pré-DVCS, en utilisant ce que l'on appelle des " systèmes de gestion de la qualité ". demandes de téléchargement .

Le concept en bref : Le développeur commet sur son propre clone, puis demande au propriétaire du dépôt principal de transférer le contenu vers le dépôt principal. Le propriétaire examine la demande et peut accepter ou refuser de la transférer dans le répertoire principal. C'est aussi simple que cela.

Vous pouvez regarder le Démonstration des flux de travail Git : Qu'est-ce que le flux de travail de l'intégrateur ? vidéo sur YouTube. Cela s'applique également à Mercurial.

Answer 4

Il y a maintenant un nom d'extension FileReview qui est intégré avec TortoiseHg (à partir de TortoiseHg >= 0.9). Les revues semblent être intégrées dans le référentiel.

Je n'ai pas réussi à le faire fonctionner sous Windows, mais j'espère qu'il sera amélioré !