Há muita documentação do "Git for Perforce users" disponível, mas aparentemente muito pouco do contrário.

Eu só usei o Git anteriormente e recentemente comecei um trabalho em que tenho que usar muito o Perforce, e me pego ficando muito confuso a maior parte do tempo. Os conceitos que estou acostumado com o Git parecem não mapear para o Perforce.

Alguém está interessado em reunir algumas dicas para usar o Perforce para alguém acostumado ao Git?

Isso é algo que eu tenho trabalhado nas últimas duas semanas. Ainda está evoluindo, mas pode ser útil. Observe que sou um funcionário da Perforce.

Uma introdução aos usuários do Perforce for Git

Dizer que mudar do Git para o Perforce ou do Perforce para o Git não é trivial é um grande eufemismo. Por serem duas ferramentas que ostensivamente fazem a mesma coisa, sua abordagem não poderia ser mais diferente. Este breve artigo tentará ajudar os novos usuários do Perforce vindos do Git a entender o novo mundo em que estão.

Um breve desvio antes de mergulharmos; Se você prefere o Git, pode usar o Git com Perforce muito bem. Fornecemos uma ferramenta chamada Git Fusion que gera repositórios Git que são mantidos em sincronia com o servidor Perforce. As pessoas Git e Perforce podem viver em harmonia trabalhando no mesmo código, principalmente não afetadas pela opção de controle de versão de seus colegas de trabalho. O Git Fusions 13.3 está disponível no site da Perforce . Ele precisa ser instalado pelo administrador do Perforce, mas se você o instalar, verá que seu recurso de divisão de repositório pode ser bastante útil como usuário do Git.

Se você não consegue convencer seu administrador a instalar o Git Fusion, o próprio Git vem com uma ligação do Perforce chamada Git-P4, que permite usar o Git para alterar e enviar arquivos em um espaço de trabalho do Perforce. Mais informações sobre isso podem ser encontradas em: https://git.wiki.kernel.org/index.php/GitP4

Ainda aqui? Bom, vamos dar uma olhada no Perforce.

Algumas diferenças de terminologia a serem resolvidas

Antes de entrarmos em detalhes, precisamos cobrir brevemente algumas diferenças de terminologia entre Git e Perforce.

O primeiro é o checkout . No Git, é assim que você obtém uma cópia do código de um determinado ramo na sua área de trabalho. No Perforce, chamamos isso de sincronização na linha de comando ou em nossa GUI P4V "Get Latest Revision". O Perforce usa a palavra checkout do P4V ou p4 editda linha de comando para indicar que você planeja alterar um arquivo do sistema de controle de versão. No restante deste documento, usarei checkout no sentido Perforce da palavra.

O segundo é o commit do Git versus o envio do Perforce . Onde você se comprometeria no Git, você enviará no Perforce. Como todas as operações acontecem no serviço de versão compartilhado do Perforce, o Perforce não tem um equivalente git push. Da mesma forma, não temos um pull; o comando sync acima cuida de obter arquivos para nós. Não existe o conceito de envio local puro no Perforce, a menos que você opte por usar nossa ferramenta P4Sandbox descrita brevemente abaixo.

Conceitos-chave no Perforce

Se eu simplificasse o Perforce para dois conceitos-chave, focaria no depósito e na área de trabalho. Um depósito do Perforce é um repositório de arquivos que vive em um servidor Perforce. Um servidor Perforce pode ter qualquer número de depósitos e cada depósito pode conter qualquer número de arquivos. Frequentemente, você ouvirá os usuários do Perforce usarem depósito e servidor de forma intercambiável, mas eles são diferentes. Um site Perforce pode optar por ter vários servidores, mas geralmente todos os arquivos estão em um servidor.

Um espaço de trabalho ou cliente do Perforce é um objeto no sistema que mapeia um conjunto de arquivos no servidor Perforce para um local no sistema de arquivos do usuário. Todo usuário tem um espaço de trabalho para cada máquina que usa, e freqüentemente os usuários terão mais de um espaço de trabalho para a mesma máquina. A parte mais importante de uma área de trabalho é o mapeamento ou visualização da área de trabalho.

A visualização da área de trabalho especifica o conjunto de arquivos no depósito que devem ser mapeados para a máquina local. Isso é importante porque há uma boa chance de você não desejar todos os arquivos disponíveis no servidor. Uma visualização da área de trabalho permite selecionar apenas o conjunto de seu interesse. É importante observar que uma área de trabalho pode mapear o conteúdo de vários depósitos, mas pode mapear apenas o conteúdo de um servidor.

Para comparar o Perforce ao Git a esse respeito, com o Git, você escolhe o conjunto de repositórios do Git em que está interessado. Cada repositório geralmente tem um escopo restrito para conter apenas arquivos relacionados. A vantagem disso é que não há configuração para você fazer; você faz um clone das coisas de que gosta e acaba. Isso é especialmente bom se você trabalhar apenas com um ou dois repositórios. Com o Perforce, você precisa gastar um pouco de tempo escolhendo e escolhendo os bits de código que deseja.

Muitas lojas Perforce usam fluxos que podem gerar automaticamente uma visualização da área de trabalho ou geram a visualização usando scripts ou áreas de trabalho de modelo. Igualmente, muitos deixam seus usuários para gerar seus próprios espaços de trabalho. Uma vantagem de poder mapear vários módulos em um espaço de trabalho é que você pode modificar facilmente vários módulos de código em um check-in; você pode garantir que qualquer pessoa com uma visão semelhante do cliente que sincronize com o seu check-in terá todo o código no estado correto. Isso também pode levar a códigos excessivamente dependentes; a separação forçada do Git pode levar a uma melhor modularidade. Felizmente, o Perforce também pode suportar modularidade estrita. É tudo uma questão de como você escolhe usar a ferramenta.

Por que espaços de trabalho?

Eu acho que, vindo do Git, é fácil sentir que todo o conceito de espaço de trabalho é muito mais problemático do que vale a pena. Comparado à clonagem de alguns repositórios Git, isso é sem dúvida verdade. Onde os espaços de trabalho brilham, e a razão pela qual o Perforce ainda está no mercado depois de todos esses anos, é que os espaços de trabalho são uma maneira fantástica de reduzir projetos de milhões de arquivos para desenvolvedores, facilitando a criação e o lançamento para reunir toda a fonte uma fonte autorizada. Os espaços de trabalho são um dos principais motivos pelos quais o Perforce pode escalar tão bem quanto ele.

Os espaços de trabalho também são bons, pois o layout dos arquivos no depósito e o layout na máquina do usuário podem variar, se necessário. Muitas empresas organizam seus depósitos para refletir a organização da empresa, para que seja fácil para as pessoas encontrarem conteúdo por unidade de negócios ou projeto. No entanto, seu sistema de construção não se importava com essa hierarquia; o espaço de trabalho permite remapear sua hierarquia de depósito da maneira que fizer sentido para suas ferramentas. Eu também vi isso usado por empresas que usam sistemas de construção extremamente inflexíveis que exigem que o código esteja em configurações muito específicas que são totalmente confusas para os seres humanos. Os espaços de trabalho permitem que essas empresas tenham uma hierarquia de origem que seja navegável por humanos, enquanto suas ferramentas de construção obtêm a estrutura de que precisam.

As áreas de trabalho no Perforce não são usadas apenas para mapear o conjunto de arquivos com os quais o usuário deseja trabalhar, mas também são usadas pelo servidor para rastrear exatamente quais revisões de cada arquivo o usuário sincronizou. Isso permite que o sistema envie o conjunto correto de arquivos ao usuário durante a sincronização sem ter que varrer os arquivos para ver quais arquivos precisam ser atualizados. Com grandes quantidades de dados, isso pode ser um ganho considerável de desempenho. Isso também é muito popular em setores que possuem regras de auditoria muito rigorosas; Os administradores do Perforce podem rastrear e registrar com facilidade quais desenvolvedores sincronizaram quais arquivos.

Para obter mais informações sobre todo o poder das áreas de trabalho do Perforce, leia Configurando o P4 .

Saída explícita x saída implícita

Um dos maiores desafios para os usuários que estão migrando do Git para o Perforce é o conceito de checkout explícito. Se você está acostumado com o fluxo de trabalho Git / SVN / CVS de alterar arquivos e depois instruir o sistema de controle de versão a procurar o que você fez, pode ser uma transição extremamente dolorosa.

A boa notícia é que, se você escolher, poderá trabalhar com um fluxo de trabalho no estilo Git no Perforce. No Perforce, você pode definir a opção "allwrite" no seu espaço de trabalho. Isso informará ao Perforce que todos os arquivos devem ser gravados no disco com o conjunto de bits gravável. Você pode alterar qualquer arquivo que desejar, sem informar explicitamente ao Perforce. Para que o Perforce reconcilie as alterações que você fez, você pode executar o "status p4". Ele abrirá arquivos para adicionar, editar e excluir, conforme apropriado. Ao trabalhar dessa maneira, você desejará usar "p4 update" em vez de "p4 sync" para obter novas revisões do servidor; "p4 update" verifica as alterações antes da sincronização, para não prejudicar as alterações locais se você ainda não tiver executado o "status p4".

Por que saída explícita?

Uma pergunta que recebo com frequência é "por que você deseja usar o checkout explícito?" No início, pode parecer uma decisão de design maluca, mas o checkout explícito tem alguns benefícios poderosos.

Uma razão para usar a verificação explícita é que ela remove a necessidade de verificar os arquivos em busca de alterações no conteúdo. Embora em projetos menores o cálculo de hashes para cada arquivo para encontrar diferenças seja bastante barato, muitos de nossos usuários têm milhões de arquivos em um espaço de trabalho e / ou arquivos com centenas de megabytes de tamanho, se não maiores. O cálculo de todos os hashes nesses casos consome muito tempo. A verificação explícita permite ao Perforce saber exatamente com quais arquivos ele precisa trabalhar. Esse comportamento é um dos motivos pelos quais o Perforce é tão popular em grandes indústrias de arquivos, como nas indústrias de jogos, filmes e hardware.

Outro benefício é o checkout explícito, que fornece uma forma de comunicação assíncrona que permite que os desenvolvedores saibam geralmente no que seus colegas estão trabalhando ou pelo menos onde. Ele pode informar que você pode querer evitar trabalhar em uma determinada área para evitar um conflito desnecessário, ou pode alertá-lo para o fato de que um novo desenvolvedor da equipe entrou no código que talvez não seja necessário. estar editando. Minha experiência pessoal é que tenho a tendência de trabalhar no Git ou usar o Perforce com allwrite em projetos nos quais sou o único colaborador ou um colaborador pouco frequente e fazer checkout explícito quando estou trabalhando em equipe. Felizmente, a escolha é sua.

A verificação explícita também funciona bem com o conceito Perforce de listas de alterações pendentes. As listas de alterações pendentes são grupos em que você pode colocar seus arquivos abertos para organizar seu trabalho. No Git, você potencialmente usaria ramificações diferentes como baldes para organizar o trabalho. As ramificações são ótimas, mas às vezes é bom poder organizar seu trabalho em várias alterações nomeadas antes de realmente enviar ao servidor. Com o modelo Perforce de mapear potencialmente várias ramificações ou vários projetos em um espaço de trabalho, as listas de alterações pendentes facilitam a organização de alterações separadas.

Se você usa um IDE para desenvolvimento como Visual Studio ou Eclipse, recomendo instalar um plug-in Perforce para seu IDE. A maioria dos plugins IDE efetuará o checkout dos arquivos automaticamente quando você começar a editá-los, liberando a necessidade de fazer o checkout por conta própria.

Substituições Perforce para recursos Git

• git stash ==> p4 shelve
• ramificação local git ==> prateleiras Perforce ou ramificações de tarefas
• git blame==> p4 annotateou Perforce Timelapse View na GUI

Trabalho desconectado

Existem duas opções para trabalhar desconectado do serviço de versão do Perforce (esse é o nosso termo mais sofisticado para o servidor Perforce).

1) Use o P4Sandbox para ter versão local completa e ramificação local

2) Edite os arquivos como desejar e use 'p4 status' para dizer ao Perforce o que você fez

Com as duas opções acima, você pode optar por usar a configuração "allwrite" no seu espaço de trabalho para não precisar desbloquear arquivos. Ao trabalhar neste modo, você desejará usar o comando "p4 update" para sincronizar novos arquivos em vez de "p4 sync". "p4 update" verificará os arquivos em busca de alterações antes de sincronizá-los.

Início rápido do Perforce

Todos os exemplos a seguir serão via linha de comando.

1) Configure sua conexão com o Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Você pode colar essas configurações no arquivo de configuração do shell, usá p4 set-las para salvá-las no Windows e no OS X ou usar um arquivo de configuração do Perforce.

1) Crie um espaço de trabalho

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Obtenha os arquivos do servidor

cd /Users/matt/work
p4 sync

3) Finalize o arquivo no qual deseja trabalhar e modifique-o

p4 edit main/foo; 
echo cake >> main/foo

4) Envie para o servidor

p4 submit -d "A trivial edit"

5) Execute p4 help simplepara ver os comandos básicos que você precisará para trabalhar com o Perforce.

A maior diferença entre git e p4, que nenhuma das respostas existentes aborda, é que elas usam diferentes unidades de abstração.

• No git, a abstração é o patch (aka diff, aka changeset). Uma confirmação no git é essencialmente a saída da execução diffentre o estado anterior e o atual dos arquivos que estão sendo confirmados.
• Em força, a abstração é o arquivo . Uma confirmação na p4 é o conteúdo completo dos arquivos na confirmação naquele momento. Isso é organizado em uma lista de alterações, mas as próprias revisões são armazenadas por arquivo e a lista de alterações simplesmente coleta diferentes revisões dos arquivos.

Tudo o resto flui dessa diferença . Ramificar e mesclar no git é indolor, porque, da perspectiva da abstração do git, todo arquivo pode ser totalmente reconstruído aplicando um conjunto de patches em ordem e, portanto, para mesclar dois ramos, basta aplicar todos os patches no ramo de origem que não estão presentes na ramificação de destino na ramificação de destino na ordem correta (supondo que não haja correções nos dois ramos que se sobreponham).

Os ramos do Forforce são diferentes. Uma operação de ramificação no perforce copiará arquivos de uma subpasta para outra e marcará a ligação entre os arquivos com metadados no servidor. Para mesclar um arquivo de uma ramificação para outra ( integrationem termos forçados), o perforce examinará o conteúdo completo do arquivo na 'cabeça' de na ramificação de origem e o conteúdo completo do arquivo na cabeça da ramificação de destino e se necessário, mescle usando um ancestral comum. É incapaz de aplicar patches um por um, como o git can, o que significa que mesclagens manuais acontecem com mais frequência (e tendem a ser mais dolorosas).

Provavelmente não existe muita documentação, porque o Perforce é um sistema de controle de revisão bastante tradicional (mais próximo do CVS, Subversion etc.) e normalmente é considerado menos complicado do que os sistemas de controle de revisão distribuídos modernos.

Tentar mapear comandos de um para o outro não é a abordagem correta; os conceitos dos sistemas de controle de revisão centralizado versus distribuído não são os mesmos. Em vez disso, descreverei um fluxo de trabalho típico no Perforce:

1. Execute p4 editem cada arquivo que você deseja editar. Você precisa informar ao Perforce quais arquivos você está editando. Se você estiver adicionando novos arquivos, use p4 add. Se você estiver excluindo arquivos, use p4 delete.
2. Faça as alterações no seu código.
3. Execute p4 changepara criar um conjunto de alterações. Aqui você pode criar uma descrição da sua alteração e, opcionalmente, adicionar ou remover arquivos do seu conjunto de alterações. Você pode executar p4 change CHANGE_NUMBERpara editar a descrição posteriormente, se necessário.
4. Você pode fazer alterações adicionais no código, se necessário. Se você precisar adicionar / editar / excluir outros arquivos, poderá usar p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Execute p4 syncpara obter as alterações mais recentes do servidor.
6. Execute p4 resolvepara resolver qualquer conflito de sincronização.
7. Quando você estiver pronto para enviar sua alteração, execute p4 submit -c CHANGE_NUMBER.

Você pode usar p4 revertpara reverter suas alterações nos arquivos.

Observe que você pode trabalhar em vários conjuntos de alterações simultaneamente, desde que nenhum dos arquivos se sobreponha. (Um arquivo no seu cliente Perforce pode ser aberto em apenas um conjunto de alterações por vez.) Isso às vezes pode ser conveniente se você tiver pequenas alterações independentes.

Se você precisar editar arquivos que você já abriu em outro conjunto de alterações, poderá criar um cliente Perforce separado ou ocultar seu conjunto de alterações existente para via posterior p4 shelve. (Ao contrário git stash, as prateleiras não revertem os arquivos na árvore local, portanto, você deve revertê-los separadamente.)