synchronisation git-p4 ne fonctionne pas - mystérieuse trace de la pile

Question

Je suis en train d'utiliser git-p4 pour clone Perforce dépôt. Je continue à courir un problème dans le script git-p4, où tente git-p4 d'accéder à une clé dict non défini et jette une trace.

[~/p4/prod@ernie02] (master) $ 
git p4 sync --verbose --use-client-spec //depot/prod/
Reading pipe: git config git-p4.user
Reading pipe: git config git-p4.password
Reading pipe: git config git-p4.port
Reading pipe: git config git-p4.host
Reading pipe: git config git-p4.client
p4 -u mkramer -c mkramer -G client -o
Opening pipe: p4 -u mkramer -c mkramer -G client -o
None
Doing initial import of //depot/prod/ from revision #head into refs/remotes/p4/master
p4 -u mkramer -c mkramer -G files //depot/prod/...#head
Opening pipe: p4 -u mkramer -c mkramer -G files //depot/prod/...#head
commit into refs/remotes/p4/master
p4 -u mkramer -c mkramer -G -x - print
Opening pipe: p4 -u mkramer -c mkramer -G -x - print
p4 -u mkramer -c mkramer -G users
Opening pipe: p4 -u mkramer -c mkramer -G users
Traceback (most recent call last):
  File "/home/mkramer/git/bin/git-p4", line 1922, in <module>
    main()
  File "/home/mkramer/git/bin/git-p4", line 1917, in main
    if not cmd.run(args):
  File "/home/mkramer/git/bin/git-p4", line 1651, in run
    self.importHeadRevision(revision)
  File "/home/mkramer/git/bin/git-p4", line 1461, in importHeadRevision
    self.commit(details, self.extractFilesFromCommit(details), self.branch, self.depotPaths)
  File "/home/mkramer/git/bin/git-p4", line 1063, in commit
    data = file['data']
KeyError: 'data'

je suis entré dans le script et imprimé le fichier dict juste à ce moment-là et a obtenu quelques détails que je corrigerai pour plus de clarté et l'anonymat. Le dict défectueux ressemblait à ceci:

{'action': 'move/delete', 'path': '//depot/prod/foo/bar', 'rev': '3', 'type': 'xtext'}

Mon client p4 ressemble à ceci:

Client: mkramer
Update: 2010/04/27 14:46:10
Access: 2010/04/27 14:51:29

Owner:  mkramer
Description:
        Created by mkramer.
Root:   z:\p4
AltRoots:
        z:\p4
        /home/mkramer/p4
Options:        noallwrite noclobber nocompress unlocked nomodtime normdir
SubmitOptions:  submitunchanged
LineEnd:        share
View:

        //depot/prod/... //mkramer/prod/...
        -//depot/.../foo/... //mkramer/.../foo/...

Comme vous pouvez le voir, le dict défectueux est un fichier qui n'existe pas à mon avis client. Je crois que c'est la source du problème. Cependant, je suis en cours d'exécution clairement la commande avec --use-client-spec. J'ai aussi essayé git config git-p4.useclientspec true La sortie verbeuse fait ressembler à ça tire mon avis sur

Opening pipe: p4 -u mkramer -c mkramer -G client -o.  

Si je cours p4 -u mkramer -c mkramer client -o je vois la vue correcte.

Si je cours p4 -u mkramer -c mkramer files //depot/prod/...#head je vois des fichiers qui ne sont pas à mon avis.

Les versions de mon logiciel:

[~/p4/prod@ernie02] (master) $ p4 -V
Perforce - The Fast Software Configuration Management System.
Copyright 1995-2009 Perforce Software.  All rights reserved.
Rev. P4/LINUX26X86_64/2009.1/205670 (2009/06/29).
[~/p4/prod@ernie02] (master) $ git --version
git version 1.7.0.5
[~/p4/prod@ernie02] (master) $ python -V
Python 2.6.5

Answer 1

Je viens de croiser nous-mêmes. P4 semble avoir ajouté quelques nouvelles commandes de l'année dernière que git-p4 ne supporte pas complètement; en particulier "déplacer / supprimer" et "déplacer / ajouter".

Pour contourner le problème, nous avons changé la ligne:

if file["action"] in ("delete", "purge"):

à:

if file["action"] in ("delete", "purge", "move/delete"):

Jusqu'à présent, cela fonctionne pour nous, mais je ne vais pas affirmer que cela est nécessairement une solution robuste.

Answer 2

Ceci est un bug qui a été corrigé dans les versions récentes de git-p4 utilisant essentiellement le patch fourni par rbergman. Voir http://git.kernel.org/ ? p = git / git.git; a = commettre; h = 562d53fa69933b3ade2691b99cbe67722313f43c pour plus de détails; ce patch est apparu probablement dans un des derniers 1.6.x et versions est sans aucun doute dans les versions 1.7.x de git.