Déterminer la dernière liste de modifications synchronisée avec Perforce


117

Une question qui se pose parfois est de savoir quel est le meilleur moyen de déterminer la liste des modifications avec laquelle vous vous êtes synchronisé pour la dernière fois dans Perforce. Ceci est souvent nécessaire pour des choses comme l'injection du numéro de la liste de modifications dans les informations de révision par le système de construction automatique.


p4 changes | head -1semble plus facile que la plupart de ces solutions.
Sridhar Sarnobat

Réponses:


91

Je recommande le contraire pour les systèmes de construction automatique: vous devez d'abord obtenir la dernière liste de modifications du serveur en utilisant:

p4 changes -s submitted -m1

puis synchronisez cette modification et enregistrez-la dans les informations de révision. La raison en est la suivante. Bien que Perforce recommande ce qui suit pour déterminer la liste des modifications avec 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 de l'espace de travail en question.
  • Il est également possible qu'un espace de travail client ne soit synchronisé avec aucune liste de modifications spécifique.

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

  • Si la liste de modifications la plus élevée à laquelle la synchronisation s'est produite a strictement supprimé des fichiers de l'espace de travail, la liste de modifications la plus élevée suivante sera signalée (à moins qu'elle ne supprime également strictement les 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é mordu par les pièges ci-dessus; il doit indiquer que rien n'a été synchronisé ou supprimé:

p4 sync -n @changelist_number

Pourquoi est-ce que "Cela ne fonctionne que si vous n'avez rien soumis de l'espace de travail en question."?
gdw2

Si vous soumettez une modification, «p4 changes -s submit -m1» renverra votre numéro de liste de modifications. Par exemple, disons que vous synchronisez avec la liste des modifications 5, attendez quelques heures, puis soumettez la liste des modifications 10. La commande de modification ci-dessus renverra 10.
Rinn

Le lien est mort, était-ce cet article? answers.perforce.com/articles/KB/3458/
user31389

Notez que vous pouvez utiliser à la #haveplace de @clientname, ce qui vous évite d'avoir à rechercher le nom de votre espace de travail client.
yoyo

29

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

Depuis la ligne de commande, utilisez:

p4 changes -m1 @<clientname>

Et remplacez simplement par le nom de votre spécification client. Cela produira la sortie du formulaire:

Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'

Ce qui est facilement analysé pour extraire le numéro de la liste de modifications.


Je reçois: Demande trop volumineuse (plus de 1500000); voir 'p4 help maxresults'.
user674669

@ user674669: utilisez l'option -m1 qui ne renvoie que la dernière (1) liste des modifications
panako

Cela donne les informations de la dernière liste de modifications soumise , et non de la dernière liste de modifications synchronisée , ce que l'op voulait savoir.
Andreas

@marsh Je pense que c'est en fait le nom de l'espace de travail client, qui par défaut est le nom de l'ordinateur s'il n'est pas défini. Voir ici: P4CLIENT .
Andreas Haferburg

15

Vous pouvez essayer de trouver le nombre maximum de modifications dans la sortie de la commande "p4 files". Le répertoire de travail ne doit pas contenir de commits post-sync. C'est juste un peu mieux que

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

car ce dernier semble fonctionner sur le serveur et peut échouer sur de grandes arborescences sources 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 JTGoldstone, Kodak Information Network / Ofoto, 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

10

Si vous utilisez P4V, vous pouvez le faire graphiquement:

  • Dans l'onglet Tableau de bord (Affichage-> Tableau de bord), choisissez un dossier et vous verrez une liste des listes de modifications avec lesquelles le dossier n'est pas encore mis à jour. Notez le nombre le plus bas (dans la ligne la plus élevée).
  • Assurez-vous que dans l'arborescence de l'espace de travail, vous avez sélectionné le même dossier que précédemment dans le tableau de bord. Ensuite, allez dans l'onglet Historique (Affichage-> Historique) et faites défiler jusqu'au numéro noté précédemment. Le nombre juste en dessous de ce nombre est le numéro de votre liste de modifications actuelle.

9

p4 changes -m1 @clientname ce qui est la manière «recommandée» de le 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


Quel est le nom du client? Comment puis-je trouver ces informations?
marsh

1
@marsh nom du client (ou également de l'espace de travail) est le nom d'un objet perforce qui contient le mappage du dépôt du serveur vers votre système de fichiers local
gsf

2
En votant pour cette réponse, car elle répond à la question réelle plutôt que de dire «ne faites pas cela» (ce qui est un point valable, mais ne répond pas à la question).
sam hocevar

1
p4 changes -m1 @clientnamecourir sans fin ... p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'fonctionne vraiment! Merci!
simomo

@gsf - merci, je viens de l'essayer sur ma machine Linux et cela a fonctionné!

8

Vous pouvez également utiliser la commande cstat:

p4 aide cstat

cstat -- Dump change/sync status for current client

p4 cstat [files...]

Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.

The fields that cstat displays are:

    change   changelist number
    status   'have', 'need' or 'partial'

5

Pour une construction sérieuse (qui est en cours de préparation pour les tests), spécifiez explicitement le numéro d'étiquette ou de liste de modifications souhaité, synchronisez-la avec l'étiquette et insérez-la dans les artefacts de construction.

Si aucune liste de p4 counter changemodifications (ou étiquette) n'est fournie, utilisez pour obtenir le numéro de modification actuel et enregistrez-le. Mais vous devez toujours tout synchroniser à l'aide de ce numéro de modification.

Je ne pense pas que vous puissiez réaliser exactement ce que vous voulez, car en général, un espace de travail entier n'est pas synchronisé avec un numéro de liste de modifications particulier. On peut explicitement synchroniser certains fichiers avec des révisions plus anciennes, puis un seul numéro de liste de modifications n'a pas de sens. C'est pourquoi une nouvelle version syncest nécessaire pour garantir qu'un seul numéro de liste de modifications représente avec précision la version du code.


Concernant les commentaires: Oui, ma réponse est destinée à être utilisée par les gestionnaires de configuration préparant une build à donner au QA. Nos développeurs ne se synchronisent normalement pas dans le cadre d'une construction; ils font une compilation avant de soumettre - afin de s'assurer que leurs modifications n'interrompent pas la compilation ou les tests. Dans ce contexte, nous ne prenons pas la peine d'intégrer une étiquette de référentiel.

Avec votre approche, vous supposez que tout votre espace de travail a été synchronisé à la tête au moment de votre dernière soumission de liste de modifications, et que cette liste de modifications comprenait tous vos fichiers ouverts. Il est trop facile de se tromper dans ces hypothèses, difficile à détecter et horriblement coûteux en termes de temps perdu. D'un autre côté, résoudre le problème est facile, sans inconvénient. Et comme un numéro de liste de modifications peut être spécifié explicitement, peu importe la révision dont vous avez besoin ou la rapidité avec laquelle la base de code change.


Erickson - belle suggestion, mais je pense qu'elle couvre un ensemble de circonstances légèrement différent de la réponse que j'ai fournie. Le compteur fonctionnera certainement si vous n'avez que la révision principale et que le serveur n'est pas assez occupé pour que quelqu'un, travaillant peut-être sur un autre projet, ne fasse pas de soumission entre la synchronisation et l'appel de p4 counter. Donc, je pense que votre suggestion est probablement meilleure lorsque le système de construction fait une traction distincte puis construit. Ma réponse couvre les cas où la synchronisation peut être séparée dans le temps de la construction. Les deux sont valables selon les circonstances, je pense.
Greg Whitfield

3

Pour tout le dépôt (pas seulement votre espace de travail / client)

p4 counter change

fait le travail, il suffit de dire la dernière liste de modifications.


2
Notez que cela indique le numéro de la dernière liste de modifications du dépôt, INCLUANT les listes de modifications en attente (c'est-à-dire non encore soumises). Ainsi, tout utilisateur commençant un nouveau travail dans son client affectera ce nombre. Ce sera différent de la dernière liste de modifications synchronisée avec l'espace de travail local.
jasonmray

2

Le mieux que j'ai trouvé jusqu'à présent est de faire votre synchronisation avec la liste de modifications que vous souhaitez créer, puis d'utiliser changes -m1 //...#have pour obtenir la liste de modifications locale actuelle (révision).

p4 sync @CHANGELIST_NUM p4 change -m1 //...#have | awk '{print $ 2}'

Vous donne le numéro de la liste des modifications que vous pouvez utiliser où vous le souhaitez. Je recherche actuellement un moyen plus simple que p4 change -m1 //...#have.


0

Je ne sais pas si vous avez obtenu la réponse dont vous aviez besoin, mais j'ai eu un problème similaire. Le but était d'écrire dans notre logger la version spécifique du projet. Le problème était que pendant que nous créions notre propre makefile, le système de construction global est contrôlé par notre gestion de la configuration. Cela signifie que toutes les solutions qui disent "synchroniser avec quelque chose puis faire quelque chose" ne fonctionnent pas vraiment et je ne voulais pas changer manuellement la version chaque fois que nous nous engageons (une source sûre pour les erreurs). La solution (qui est en fait suggérée dans certaines des réponses ci-dessus) est la suivante: dans notre makefile, je fais des changements p4 -m1 "./...#have" Le résultat est Change change_number on date by user @ client ' msg ' Je crée simplement le message dans une chaîne qui est imprimée par l'enregistreur (le numéro de modification est l'élément important mais l'autre est également utile pour décider rapidement si une certaine version contient des modifications que vous savez que vous avez faites vous-même sans aller forcément vérifier). J'espère que cela t'aides.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.