Détermination de la dernière liste de changements synchronisée dans Perforce

Question

Une question qui se pose parfois est de savoir quelle est la meilleure façon de déterminer la liste de changements à laquelle vous avez synchronisé pour la dernière fois dans Perforce. Cela est souvent nécessaire pour des choses comme injecter le numéro de la liste de changements dans les informations de révision par le système de build automatique.

Answer 1

Je recommande l'opposé pour les systèmes de construction automatique : vous devriez d'abord obtenir la dernière liste de changements du serveur en utilisant :

p4 changes -s submitted -m1

puis synchroniser ce changement et l'enregistrer dans les informations de révision. La raison en est la suivante. Bien que Perforce recommande ce qui suit pour déterminer la liste de changements à laquelle l'espace de travail est synchronisé :

p4 changes -m1 @clientname

ils notent quelques pièges :

• Cela ne fonctionne que si vous n'avez rien soumis depuis l'espace de travail en question.
• Il est également possible qu'un espace de travail client ne soit pas synchronisé sur une liste de changements spécifique.

et il y a un autre piège qu'ils ne mentionnent pas :

• Si la liste de changements la plus élevée à laquelle la synchronisation s'est produite a strictement supprimé des fichiers de l'espace de travail, la liste de changements suivante la plus élevée sera signalée (à moins qu'elle aussi n'ait strictement supprimé des fichiers).

Si vous devez d'abord synchroniser et enregistrer plus tard, Perforce recommande d'exécuter la commande suivante pour déterminer si vous avez été touché par les pièges mentionnés ci-dessus ; cela devrait indiquer que rien n'a été synchronisé ou supprimé :

p4 sync -n @changelist_number

Notez que cette méthode ne fonctionne pas si un fichier est ajouté dans une liste de changements (n-1) et ensuite supprimé dans la liste de changements suivante (n). p4 changes -m1 @clientname et p4 changes ...#have renvoient tous deux n-3 et p4 sync -n @n-3 indiquera "fichier(s) à jour".

Answer 2

Juste pour répondre à moi-même en suivant la suggestion de Jeff d'utiliser Stackoverflow comme un endroit pour conserver des extraits techniques....

Depuis la ligne de commande utiliser:

p4 changes -m1 @

Et remplacer simplement par le nom de votre spécification client. Cela produira une sortie sous la forme:

Changement 12345 le 21/08/2008 par joebloggs@mainline-client '....première ligne de la description...'

Qui peut être facilement analysée pour extraire le numéro du changement.

Answer 3

Vous pouvez essayer de trouver le numéro de changement maximal dans la sortie de la commande "p4 files". Le répertoire de travail ne doit pas contenir de commits post-sync, cependant. C'est juste un peu mieux que

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

car ce dernier semble s'exécuter sur le serveur et peut échouer sur de gros arbres source en raison des limites de "MaxResults".

$ 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 présentation Using P4G.py From the Command Line par J.T.Goldstone, Kodak Information Network/Ofoto, le 15 avril 2005.

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

if os.name == "nt":
    # Désactiver la traduction des sauts de ligne sous Windows.  Les autres systèmes d'exploitation ne traduisent pas le contenu des fichiers.
    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

Answer 4

Vous pouvez également utiliser la commande cstat :

p4 help cstat

cstat -- Affiche l'état des changements/synchronisations pour le client actuel

p4 cstat [fichiers...]

Affiche les changements nécessaires, effectués ou partiellement synchronisés dans le client actuel. La sortie est renvoyée dans un format balisé, similaire à la commande fstat.

Les champs affichés par cstat sont :

    changement   numéro du changement
    état   'avoir', 'besoin' ou 'partiel'

Answer 5

Pour une construction sérieuse (celle qui est en cours de préparation pour les tests), spécifiez explicitement l'étiquette désirée ou le numéro de changement souhaité, synchronisez vers une étiquette, et incorporez-la dans les artefacts de construction.

Si aucun numéro de changement (ou étiquette) n'est donné, utilisez p4 counter change pour obtenir le numéro de changement actuel, et enregistrez-le. Mais vous devez toujours synchroniser tout en utilisant ce numéro de changement.

Je ne pense pas que vous puissiez atteindre exactement ce que vous voulez, car en général, un espace de travail entier n'est pas synchronisé vers un numéro de changement particulier. On peut synchroniser explicitement certains fichiers vers des révisions antérieures, et ensuite un seul numéro de changement est sans signification. C'est pourquoi une nouvelle synchronisation est nécessaire pour s'assurer qu'un seul numéro de changement représente correctement la version du code.

---

En ce qui concerne les commentaires : Oui, ma réponse est destinée aux gestionnaires de configuration préparant une construction à remettre à la QA. Nos développeurs ne synchronisent généralement pas dans le cadre d'une construction ; ils effectuent une construction avant de soumettre—afin de s'assurer que leurs modifications ne cassent pas la construction ou les tests. Dans ce contexte, nous ne nous embêtons pas à incorporer une étiquette de dépôt.

Avec votre approche, vous supposez que tout votre espace de travail était synchronisé vers la tête au moment de votre dernière soumission de changement, et que ce changement incluait tous vos fichiers ouverts. Il est trop facile de se tromper dans ces suppositions, difficile à détecter, et terriblement coûteux en termes de temps perdu. En revanche, résoudre le problème est facile, sans inconvénients. Et parce qu'un numéro de changement peut être spécifié explicitement, peu importe la révision dont vous avez besoin ou la rapidité avec laquelle la base de code évolue.