Determinando a última changelist sincronizada com o Perforce

Uma questão que surge ocasionalmente é qual é a melhor maneira de determinar a lista de mudanças que você sincronizou pela última vez no Perforce. Isso geralmente é necessário para coisas como injetar o número da lista de mudanças nas informações de revisão pelo sistema de compilação automática.

Eu recomendo o oposto para sistemas de construção automática: você deve primeiro obter a lista de mudanças mais recente do servidor usando:

p4 changes -s submitted -m1

em seguida, sincronize essa alteração e registre-a nas informações de revisão. A razão é a seguinte. Embora Perforce recomende o seguinte para determinar a lista de mudanças com a qual o espaço de trabalho é sincronizado:

p4 changes -m1 @clientname

eles observam algumas pegadinhas:

• Isso só funciona se você não enviou nada do espaço de trabalho em questão.
• Também é possível que um espaço de trabalho do cliente não seja sincronizado com nenhuma lista de alterações específica.

e há uma pegadinha adicional que eles não mencionam:

• Se a changelist mais alta para a qual a sincronização ocorreu excluiu estritamente os arquivos do espaço de trabalho, a próxima changelist mais alta será relatada (a menos que, também, arquivos estritamente excluídos).

Se você deve sincronizar primeiro e gravar depois, Perforce recomenda executar o seguinte comando para determinar se você foi mordido pelas pegadinhas acima; deve indicar que nada foi sincronizado ou removido:

p4 sync -n @changelist_number

Apenas para responder a essa pergunta, mantendo a sugestão de Jeff de usar Stackoverflow como um lugar para manter fragmentos técnicos ....

Na linha de comando, use:

p4 changes -m1 @<clientname>

E apenas substitua pelo nome da especificação do seu cliente. Isso produzirá a saída do formulário:

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

Que é facilmente analisado para extrair o número da lista de mudanças.

Você pode tentar encontrar o número máximo de alteração na saída do comando "arquivos p4". O diretório de trabalho não deve conter commits pós-sincronização, no entanto. Isso é um pouco melhor do que

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

já que o último parece funcionar no servidor e pode falhar em grandes árvores de origem devido aos 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

onde p4lastchange.py é baseado no código da apresentação Using P4G.py From the Command Line de JTGoldstone, Kodak Information Network / Ofoto, 15 de abril de 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

Se estiver usando P4V, você pode fazer isso graficamente:

• Na guia Dashboard (Exibir-> Dashboard) escolha uma pasta e você verá uma lista de changelists com as quais a pasta ainda não foi atualizada. Observe o número mais baixo (na linha mais alta).
• Certifique-se de que na Árvore da Área de Trabalho você selecionou a mesma pasta que anteriormente no Painel. Em seguida, vá para a guia Histórico (Exibir-> Histórico) e role para baixo até o número anotado anteriormente. O número logo abaixo desse número é o número da sua lista de mudanças atual.

p4 changes -m1 @clientname que é a maneira "recomendada" de fazer isso para meu cliente leva cerca de 10 minutos

isso é o que eu uso:

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

para o mesmo cliente leva 2,1 segundos

Você também pode usar o comando cstat:

p4 help 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'

Para um build sério (aquele que está sendo preparado para teste), especifique explicitamente o rótulo desejado ou número da lista de mudanças, sincronize com o rótulo e inclua-o nos artefatos de compilação.

Se uma changelist (ou rótulo) não for fornecido, use p4 counter changepara obter o número da alteração atual e registre-o. Mas você ainda precisa sincronizar tudo usando esse número de alteração.

Não acho que você possa conseguir exatamente o que deseja, porque, em geral, um espaço de trabalho inteiro não é sincronizado com um número de changelist específico. É possível sincronizar explicitamente alguns arquivos para revisões mais antigas e, então, um único número da lista de mudanças não faz sentido. É por isso que um novo syncé necessário para garantir que um único número da lista de mudanças represente com precisão a versão do código.

Com relação aos comentários: Sim, minha resposta deve ser usada por gerentes de configuração que estão preparando uma construção para fornecer ao controle de qualidade. Nossos desenvolvedores normalmente não sincronizam como parte de uma construção; eles fazem uma compilação antes de enviar - para que possam ter certeza de que suas alterações não quebrem a compilação ou os testes. Nesse contexto, não nos preocupamos em incorporar um rótulo de repositório.

Com sua abordagem, você está assumindo que todo o seu espaço de trabalho foi sincronizado com o head no momento do seu último envio de changelist e que a changelist incluiu todos os seus arquivos abertos. É muito fácil se enganar nessas suposições, difíceis de detectar e terrivelmente caro em termos de tempo perdido. Por outro lado, resolver o problema é fácil, sem inconvenientes. E como um número da lista de mudanças pode ser especificado explicitamente, não importa qual revisão você precisa ou quão rápido a base de código está mudando.

Para todo o depósito (não apenas seu espaço de trabalho / cliente)

p4 counter change

faz o trabalho, apenas informando a última changelist.

O melhor que descobri até agora é fazer sua sincronização com qualquer changelist que você deseja construir e então usar as mudanças -m1 //...#have para obter a changelist local atual (revisão).

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

Dá a você o número da lista de mudanças que você pode usar onde quiser. No momento, estou procurando uma maneira mais simples do que p4 changes -m1 //...#have.

Não tenho certeza se você obteve a resposta de que precisava, mas tive um problema semelhante. O objetivo era escrever em nosso logger a versão específica do projeto. O problema é que enquanto estamos fazendo nosso próprio makefile, o sistema geral de construção é controlado por nosso gerenciamento de configuração. Isso significa que todas as soluções que dizem "sincronizar algo e depois fazer algo" realmente não funcionam e eu não queria alterar manualmente a versão sempre que confirmamos (uma fonte segura para erros). A solução (que na verdade é sugerida em algumas das respostas acima) é esta: em nosso makefile, eu faço p4 changes -m1 "./...#have" O resultado para isso é Change change_number on date by user @ client ' msg ' Eu simplesmente crio a mensagem em uma string que é impressa pelo logger (o número da alteração é o elemento importante, mas o outro também é útil para decidir rapidamente se uma determinada versão contém alterações que você sabe que fez por conta própria, sem forçar para verificar). Espero que isto ajude.