La détermination de la dernière liste de modifications synchronisé pour en Perforce

Je recommande le contraire pour la construction automatique des systèmes: vous devez d'abord obtenir la dernière liste de modifications à partir du serveur à l'aide de:

p4 changes -s submitted -m1

puis de synchroniser de la variation et de l'enregistrer dans la révision info. La raison est la suivante. Bien que Perforce recommande ce qui suit pour déterminer la liste de modifications pour qui l'espace de travail est synchronisé:

p4 changes -m1 @clientname

ils notent quelques pièges:

• Cela ne fonctionne que si vous n'avez pas soumis de rien à partir de l'espace de travail en question.
• Il est également possible qu'un client de l'espace de travail n'est pas synchronisé à une liste de modifications.

et il ya un supplément de gotcha qu'ils ne mentionnent pas:

• Si les plus hautes liste de modifications à laquelle la synchronisation s'est produite strictement fichiers supprimés à partir de l'espace de travail, le plus élevé suivant liste de modifications seront signalées (à moins que, elle aussi, strictement fichiers supprimés).

Si vous devez synchroniser premier et enregistrement plus tard, Perforce recommande d'exécuter la commande suivante pour déterminer si vous avez été mordu par le dessus de pièges; elle devrait indiquer que rien n'a été synchronisé ou supprimé:

p4 sync -n @changelist_number

Vous pouvez essayer de trouver le maximum le nombre de changement dans la sortie de la "p4 fichiers de la commande". Le répertoire de travail ne doit pas contenir de post-synchronisation s'engage, si. C'est juste un peu mieux que

p4 changes -m1 "./...#have"

que ce dernier semble s'exécuter sur le serveur et peut échouer sur une grande source d'arbres en raison de la "MaxResults" les limites.

$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.

$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657

où p4lastchange.py est basé sur le code de la À l'aide de P4G.py à Partir de la Ligne de Commande présentation par J. T. Goldstone, Kodak Réseau d'Information/Ofoto, le 15 avril 2005.

#! /usr/bin/env python
import sys, os, marshal

if os.name == "nt":
    # Disable newline translation in Windows.  Other operating systems do not
    # translate file contents.
    import msvcrt
    msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )

lastcl = 0
num = 0
try:
    while 1:
        dict = marshal.load(sys.stdin)
        num = num + 1
        for key in dict.keys():
            # print "%s: %s" % (key,dict[key])
            if key == "change":
                cl = int(dict[key])
                if cl > lastcl:
                    lastcl = cl
except EOFError:
    pass
print "Files: %s" % num
print lastcl

p4 changes -m1 @clientname qui est le "recommandé" façon de faire pour mon client prend environ 10 minutes

c'est ce que j'utilise:

p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'

pour le même client prend 2,1 secondes

Pour une grave construire (celui qui est en cours de préparation pour les tests), spécifier explicitement le label désiré ou modifications en nombre, de synchronisation de l'étiquette, et de l'intégrer dans construire des artefacts.

Si une liste de modifications (ou l'étiquette) n'est pas donné, utilisez p4 counter change pour obtenir le courant modifier le nombre, et de les enregistrer. Mais vous avez encore besoin de tout synchroniser à l'aide que le nombre de changement.

Je ne pense pas que vous pouvez obtenir exactement ce que vous voulez, parce qu'en général, la totalité d'un espace de travail n'est pas synchronisé à une liste numéro. On peut explicitement la synchronisation des fichiers sur d'anciennes révisions, et puis une seule liste nombre est dénuée de sens. C'est pourquoi une nouvelle sync est nécessaire pour s'assurer qu'une seule liste nombre représente exactement la version du code.

---

Concernant les commentaires: Oui, ma réponse est prévu pour l'utilisation de la configuration des gestionnaires de la préparation d'un build pour le donner à l'assurance de la qualité. Nos développeurs n'ont pas l'habitude de synchronisation dans le cadre d'une construction; ils faire un build avant de soumettre afin qu'ils puissent s'assurer que leurs modifications de ne pas briser la construction ou de tests. Dans ce contexte, nous n'avons pas pris la peine d'intégrer un référentiel label.

Avec votre approche, vous êtes en faisant l'hypothèse que l'ensemble de votre espace de travail a été synchronisé à la tête au moment de votre dernière liste de modifications de la soumission, et que les modifications inclus tous vos fichiers ouverts. C'est trop facile de se tromper dans ces hypothèses, difficile à détecter, et horriblement coûteux en termes de temps perdu. D'autre part, la résolution du problème est facile, sans les inconvénients. Et parce qu'une liste de modifications nombre peut être spécifié explicitement, il n'a pas d'importance ce que la révision dont vous avez besoin ou comment rapidement le code de base est en train de changer.

Le meilleur que j'ai trouvé pour l'instant est de faire synchroniser votre liste de modifications à tout ce que vous voulez construire et puis les changements d'utilisation -m1 //...#obtenir la liste de modifications (révision).

p4 de synchronisation @CHANGELIST_NUM
p4 changements -m1 //...#et | awk '{print $2}'

Vous donne la liste nombre que vous pouvez l'utiliser partout où vous voulez. Je suis actuellement à la recherche d'un moyen plus simple que de p4 changements -m1 //...#ont.