Déterminer la révision de base de la transaction dans le pré-engagement

Question

J'écris un crochet de pré-engagement où je voudrais appliquer une règle en fonction du contenu d'un fichier avant de la transaction. Par conséquent, lorsqu'une transaction commencera, je voudrais SVNLook Cat le contenu de tout fichier marqué "U", "UU" ou "D" sans pour autant les changements en attente. Est-il sûr pour moi de prendre l'identifiant de transaction fourni (deuxième argument pour pré-engager) et de retirer le tableau de bord et tous les caractères qui le suivent et considèrent que la "révision de base"? Existe-t-il une meilleure façon de trouver ces informations?

Answer 1

La réponse directe est non. Le numéro de transaction pourrait être n'importe quoi. Cependant, svnlook youngest <repos> retournera la dernière révision qui devrait être ce que vous recherchez.

Soyez prudent avec les crochets pré-communicés:

• Assurez-vous que vous ne faites pas quelque chose qui prendra beaucoup de temps. Les développeurs doivent attendre qu'un crochet pré-engagé se termine, et si vous prenez de 7 à 10 secondes de traitement de quelque chose, les développeurs deviennent très frustrés.
• Vous ne pouvez pas (et ne devez pas) modifier les données engagées. S'il correspond à ce que vous voulez, permettez le commit. Si ce n'est pas le cas, ne laissez pas le commit.
• Assurez-vous de ne pas arrêter ce qui pourrait être une activité légitime. Par exemple, certains sites utilisent des crochets de pré-engagement pour empêcher quelqu'un de commettre un changement à moins qu'ils ne mettent un billet dans le message de validation, et ce message de validation est un billet attribué à ce développeur, et ce billet est à l'état ouvert. Pouvez-vous imaginer l'hilarité qui s'ensuit lorsqu'un développeur ne peut pas commettre de changement parce qu'un billet est affecté à quelqu'un d'autre, et que la seule personne qui peut modifier la mission est désactivée pour la semaine?

Il y a des moments où il est préférable d'utiliser un serveur d'intégration continu pour vérifier l'engagement plutôt qu'un crochet pré-engagé ou post-engagement. Par exemple, permettez à un développeur de commettre un fichier, mais si le développeur n'est pas dans le bon groupe, envoyez peut-être un e-mail à la responsable du développement.

Il y a 90% de chances que le développeur fasse probablement la bonne chose. Ce chef de développement connaît probablement déjà le problème. Et, s'il y a un problème, vous pouvez retourner le changement.

Answer 2

La révision de la base est indécise jusqu'à ce que la révision soit engagée. Si un autre changement ne change pas les mêmes nœuds, il peut être engagé pendant que votre engagement est en cours. Seule la dernière partie de l'engagement est exclusive.

Answer 3

Et ajouter 1 au plus jeune. par exemple:

the_revision=$(svnlook youngest ${REPOS})
((the_revision++))