GIT vs. Perforce- Dois VCS vão entrar ... um vai sair [fechado]


85

Então, estou no processo de vender o GIT para o trabalho. A primeira coisa que preciso é convencer a todos que o GIT é melhor no que eles já estão acostumados a fazer. Atualmente usamos Perforce. Alguém mais passou por uma venda semelhante? Algum bom link / conselho?

Uma das grandes vitórias é que podemos trabalhar com ele desconectado da rede. Outra vitória da IMO é a maneira como as adições / checkouts são gerenciados. Mais pontos são bem-vindos! Também temos cerca de 10-20 devs no total.

Respostas:


75

O código-fonte do interpretador Perl 5 está atualmente passando pelos estertores da conversão de Perforce para git. Talvez o git-p4rawimportador de Sam Vilain seja de seu interesse.

Em qualquer caso, uma das principais vitórias que você terá sobre cada VCS centralizado e a maioria dos distribuídos também é a velocidade bruta . Você não pode imaginar como é libertador ter todo o histórico do projeto à mão, a meras frações de frações de segundo de distância, até que você tenha experimentado isso. Mesmo a geração de um log de commit de todo o histórico do projeto que inclui uma diferença completa para cada commit pode ser medido em frações de segundo. Git é tão rápido que seu chapéu vai voar. Os VCSs que precisam percorrer a rede de ida e volta simplesmente não têm chance de competir, nem mesmo por um link Gigabit Ethernet.

Além disso, o git torna muito fácil ser cuidadosamente seletivo ao fazer commits, permitindo assim que mudanças em sua cópia de trabalho (ou mesmo dentro de um único arquivo) sejam distribuídas em vários commits - e em diferentes branches se você precisar. Isso permite que você faça menos anotações mentais enquanto trabalha - você não precisa planejar seu trabalho com tanto cuidado, decidindo antecipadamente que conjunto de alterações irá confirmar e adiando qualquer outra coisa. Você pode simplesmente fazer as alterações que desejar à medida que ocorrerem e ainda desemaranhá-las - quase sempre com bastante facilidade - quando for a hora de fazer o commit. O stash pode ser uma grande ajuda aqui.

Eu descobri que, juntos, esses fatos me fazem naturalmente fazer muito mais commits focados do que antes de usar o git. Isso, por sua vez, não apenas torna seu histórico geralmente mais útil, mas é particularmente benéfico para ferramentas que agregam valor, como git bisect.

Tenho certeza de que há mais coisas em que não consigo pensar agora. Um problema com a proposta de vender sua equipe no git é que muitos benefícios estão inter-relacionados e atuam entre si, como mencionei acima, de forma que é difícil simplesmente olhar para uma lista de recursos e benefícios do git e inferir como eles vão mudar seu fluxo de trabalho e quais mudanças serão melhorias genuínas. Você precisa levar isso em consideração e também apontar isso explicitamente.


Supostamente, o p4sandbox fornece algumas habilidades offline para o p4. No entanto, ainda gosto do git. :)
Dominic Mitchell

13
O Git não fornece 'habilidades offline', ele está offline. A única coisa que você envia dados pela conexão é quando você envia commits para a origem ou puxa alterações de outros sub-repositórios.
Evan Plaice

2
"Git é tão rápido que seu chapéu vai voar" adoro isso :) A única coisa que não é muito verdade quando você começa a fazer check-in de arquivos binários. grandes repositórios são problemáticos no git.
v.oddou

1
Infelizmente é verdade. A forma como o Git funciona depende da leitura de arquivos e de alguma forma de diferenciá-los, então eles precisam ter um tamanho modesto e ser bem difundidos. Então será extremamente rápido (como no exemplo do histórico full-diff instantâneo para centenas de commits). Com bolhas enormes? Nem tanto…
Aristóteles Pagaltzis

84

Eu uso o Perforce no trabalho. Eu também uso o Git porque ainda gostaria de alguma forma de controle de versão quando estou trabalhando no código e não consigo me conectar ao servidor. Não, reconciliar o trabalho offline não é a mesma coisa. Aqui é onde descobri que o git é um grande benefício:

  1. Velocidade de ramificação - git leva alguns segundos no máximo.
  2. Conflitos - a resolução automática de P4Merge destruiu uma vez o trabalho de uma semana. Desde então, prefiro resolver manualmente ao mesclar. Quando Git me avisa sobre um conflito, na verdade é um conflito. No resto do tempo, o git resolve as coisas corretamente e economizo muito tempo.
  3. Acompanhando as fusões - se você tem uma filial que está continuamente recebendo fusões de duas outras filiais, sabe como isso pode ser uma dor de cabeça forçosamente. Com git, a dor de cabeça é minimizada porque o resultado de um merge no git é na verdade um novo commit que sabe quem são seus ancestrais.
  4. Permissões - perdi o controle do número de vezes que tentei trabalhar em um arquivo, mas não consegui porque ele não foi verificado no Perforce. Se você trabalhou com o XCode (ou qualquer editor que não tenha um plugin Perforce SCM sólido) offline, você sabe como isso pode ser irritante. Não preciso me preocupar com isso com o Git. Eu faço minhas alterações. Git não me impede e os rastreia em segundo plano.
  5. Mantendo a árvore principal organizada - Com o git, posso ordenar meus commits e organizar o código para que o histórico fique bem organizado. Nada daquilo "devolver este arquivo porque era para fazer parte do check-in anterior" lixo. Eu squash commits assim, porque eles não ajudam ninguém.
  6. Stashing - Seu servidor perforce precisa ter a versão 2010.1 ou mais recente para usar o comando p4 shelve.
  7. Criando patches - Fácil de fazer no git. Não sei se é possível no Perforce sem usar a linha de comando.
  8. Enviando patches da GUI - novamente, o git vence aqui.
  9. Espaço em disco - com o perforce, cada filial é uma cópia. Isso significa que se sua árvore de origem for enorme, seu espaço em disco será consumido rapidamente. Isso sem contar o espaço adicional depois de começar a construir. Por que ainda ter um link entre ramificações e espaço em disco? Com o git, você pode ter 100 branches e apenas um branch por vez existe. Se você deseja trabalhar especificamente em duas versões simultaneamente, pode clonar, fazer seu trabalho e depois se livrar de um clone, se quiser, sem perder nada.
  10. Se você estiver no XCode4, o suporte perforce foi descartado e o suporte git agora está integrado. Se você faz um trabalho multiplataforma como eu, isso importa muito. Com o Visual Studio, você pode usar extensões git. Com o forçar, é igualmente nojento em ambos os sistemas operacionais. Bem, talvez um pouco mais no mac agora com o XCode4 em cena.
  11. Encontrando o check-in defeituoso (ou regras git bisect) - Já tentou fazer uma pesquisa binária com o perforce para descobrir onde um bug foi introduzido? Bastante aborrecimento, sim? Ainda mais incômodo quando houver integrações de outras ramificações no meio. Por quê? Porque não há automação para tais tarefas. Você precisa escrever sua própria ferramenta para falar com forçosamente e geralmente não tem tempo. Com o git, você dá a ele os pontos de partida (o ponto "bom" e o "ruim") e ele automatiza a busca para você. Melhor ainda, se você tiver um script que pode automatizar o processo de construção e teste, pode ligar o git ao script e todo o processo de localização do check-in é automatizado. É assim que deve ser.
  12. Rastreando alterações entre refatores - tente dividir BigClass em SmallClass1 e SmallClass2. Para o Perforce, BigClass agora deixou de existir e duas novas classes (SmallClass1 e SmallClass2 se juntaram à árvore de origem). Para o Perforce, não há relação entre BigClass e SmallClass1 e SmallClass2. Git, por outro lado, é inteligente o suficiente para saber que x% do BigClass agora está em SmallClass1 e y% de BigClass está em SmallClass2 e que BigClass deixou de existir. Agora, do ponto de vista de alguém que está revisando mudanças em vários branches, você me diz qual abordagem você acha mais útil - Git ou Perforce. Pessoalmente, prefiro a abordagem do Git porque ela reflete com mais precisão a mudança real no código. O Git é capaz de fazer isso porque rastreia o conteúdo dentro do arquivo e não o arquivo em si.
  13. Centralizado ou descentralizado: Git é um sistema DVCS enquanto perforce é centralizado. Um VCS centralizado não pode ser descentralizado posteriormente, mas um DVCS (especialmente git) pode ser centralizado. Existem vários produtos que adicionam controle de acesso de baixa granularidade ao git, se isso for algo de que a empresa precisa. Pessoalmente, eu escolheria um sistema que me desse maior flexibilidade a longo prazo.
  14. Mapeamentos de ramificação: Se você deseja fazer ramificações diretamente no Perforce, você precisa criar um mapeamento de ramificações. Existem razões para isso, mas elas estão ligadas à forma como o Perforce conceitua um branch. Como desenvolvedor, ou equipe, isso significa simplesmente mais uma etapa no fluxo de trabalho, que não considero eficiente de forma alguma.
  15. Compartilhando trabalho entre equipes: Com o Perforce, você não pode interromper um envio. A Equipe A está trabalhando no recurso A. A Equipe B no recurso B. A Equipe C trabalha na correção de bugs. Agora, as equipes A e B precisam consertar um monte de bugs para implementar seus recursos. A única coisa é que eles não foram tão disciplinados ao enviar suas alterações (provavelmente porque estão correndo para um prazo) e, portanto, suas "correções de bugs" são partes de envios maiores que também contêm coisas novas, como controle de versão em seus ramos estão em causa. No entanto, a Equipe C agora está fazendo um lançamento pontual e gostaria de obter as correções de bug das outras equipes. Se eles estivessem usando o Git, o Time C poderia escolher a dedo as mudanças relevantes dos outros times, dividi-los e pegar apenas o que eles precisavam, sem se preocupar em introduzir quaisquer recursos parcialmente implementados. Com o Perforce,
  16. Mudança de plataforma - Se, por algum motivo no futuro, você decidir mudar sua plataforma de escolha, com o Perforce, você estará à mercê do Perforce.com e da disponibilidade das ferramentas para a plataforma de sua escolha.
  17. Mudar para o futuro incrível mecanismo de controle de fonte X - Se você decidir mudar o que usa para controle de fonte, extrair seu histórico de controle de fonte do Perforce e movê-lo para o novo sistema X vai ser um pesadelo, porque é um código fechado e o melhor você pode fazer é adivinhar - apenas migração do Google para Perforce para Git para ter uma ideia do que estou falando. Pelo menos com o Git, seu código-fonte aberto, elimina muitas das suposições envolvidas.

Bem, são meus 2 centavos. Em defesa do Perforce, devo dizer que suas regras de suporte ao cliente, assim como sua ferramenta Time Lapse View. Eu não sei como obter uma visão de lapso de tempo com o git. Mas para a conveniência e tempo economizado, eu iria com git qualquer dia.


2
re # 6 (stash): p4 arquivar, é novo.
Trey

Obrigado. Atualizei minha resposta :)
Carl,

8
A maior diferença entre Perforce e Git é a mentalidade necessária. Se você está administrando uma loja VCS centralizada, o git vai ser muito difícil de vender, porque requer uma mudança na maneira como você, sua equipe e a empresa pensam sobre o controle de versão. Em outras palavras, o git é uma ferramenta excelente e eficiente que é tecnicamente mais capaz do que o Perforce. A parte difícil é convencer os humanos :)
Carl

1
Estou apaixonado pelo Perforce. Ler este post parece trapacear ...
KlausCPH

2
@KlausCPH pelo menos você não terá que preparar um discurso de rompimento quando sair de Perforce :)
Carl

46

Eu precisaria de muito para me convencer a mudar de força. Nas duas empresas que usei foi mais do que adequado. Ambas eram empresas com escritórios distintos, mas os escritórios foram configurados com muita infraestrutura, então não havia necessidade de ter recursos separados / desconectados.

De quantos desenvolvedores você está falando sobre a mudança?

A verdadeira questão é - o que há sobre forçosamente que não está atendendo às necessidades da sua organização que o git pode fornecer? E da mesma forma, quais fraquezas o git tem em comparação com forçosamente? Se você mesmo não consegue responder, perguntar aqui não ajudará. Você precisa encontrar um caso de negócios para sua empresa. (por exemplo, talvez seja com menor custo geral de propriedade (que inclui perda de produtividade para o estágio de aprendizado provisório, custos administrativos mais elevados (pelo menos inicialmente), etc.)

Eu acho que você terá uma venda difícil - forçosamente é uma boa opção para tentar substituir. É um acéfalo se você está tentando inicializar o PVC ou o ssafe.


18
Acrescentarei que o notável conjunto de recursos do Git tem o custo de uma curva de aprendizado íngreme. (Embora eu também nunca tenha achado o Perforce tão intuitivo.)
savetheclocktower

1
Ótima resposta, Tim. Justin - por que seu chefe foi vendido? Certamente você deve ter respondido à pergunta de Tim para fazer isso? Eu também estaria interessado na justificativa.
Greg Whitfield,

4
Você tem que pagar pelo Perforce em um ambiente comercial, e realmente sempre achei o Perforce difícil de usar. E a única força que realmente vejo é que ele é bom para lidar com grandes bolhas binárias.
Calyth de

2
@ Justin: Cuidado com o motivo "usaremos apenas os recursos básicos". Com o git, você acabará usando as coisas mais avançadas. Por que não você? Bisect vem à mente imediatamente. Então faça rebase e escolha a dedo.
Carl

3
Na verdade, tendo uma conversa relevante nos comentários que terminou assim que o prompt "tem certeza de que não gostaria de mover isso para o bate-papo" apareceu, fez com que alguém finalmente percebesse que esta questão, de fato, não é adequada para SO. Essencialmente, está perguntando por que um sistema é "melhor" do que outro e, com isso, convida a um grande debate animado.
Adam Park em

15

Eu acho que em termos de manter as pessoas felizes durante / após a troca, uma das coisas a serem explicadas desde o início é como uma filial local pode ser privada no Git e quanta liberdade isso lhes dá para cometer erros. Faça com que todos eles clonem alguns branches privados do código atual e então vão à loucura, experimentando. Renomeie alguns arquivos, faça check-in, mescle coisas de outro branch, retroceda o histórico, rebase um conjunto de alterações sobre outro e assim por diante. Mostre como mesmo seus piores acidentes localmente não têm consequências para seus colegas. O que você quer é uma situação em que os desenvolvedores se sintam seguros, para que possam aprender mais rápido (já que o Git tem uma curva de aprendizado íngreme que é importante) e, eventualmente, para que eles sejam mais eficazes como desenvolvedores.

Quando você está tentando aprender uma ferramenta centralizada, obviamente você ficará preocupado em fazer alguma besteira que cause problemas para outros usuários do repositório. O medo do embaraço por si só é suficiente para desencorajar as pessoas de experimentar. Mesmo ter um repositório especial de "treinamento" não ajuda, porque inevitavelmente os desenvolvedores encontrarão uma situação no sistema de produção que eles nunca viram durante o treinamento e, portanto, eles voltam a se preocupar.

Mas a natureza distribuída do Git acaba com isso. Você pode tentar qualquer experiência em uma filial local e, se der terrivelmente errado, simplesmente jogue a filial fora e ninguém precisa saber. Já que você pode criar um branch local de qualquer coisa, você pode replicar um problema que está vendo com o repositório real, mas não corre o risco de "quebrar a compilação" ou de fazer papel de bobo. Você pode verificar absolutamente tudo, assim que fizer isso, sem tentar agrupar o trabalho em pequenos pacotes organizados. Portanto, não apenas as duas principais alterações de código nas quais você gastou quatro horas hoje, mas também aquela correção de compilação da qual você se lembrou no meio do caminho e o erro de ortografia na documentação que você identificou ao explicar algo a um colega e assim por diante. E se as principais mudanças forem abandonadas porque o projeto está mudando de direção,


Não há razão para que você não possa ter uma filial privada de um sistema centralizado. DVCSs às vezes se saem melhor na fusão, mas só porque o branch privado não existe no repo remoto, não significa que você não pode criar um branch apenas para você que existe no repo remoto.
Billy ONeal,

2
Este comentário é tecnicamente correto, mas está meio que perdendo o ponto. Os sistemas de controle de revisão são uma ferramenta social. Socialmente, o branch com o seu nome no servidor compartilhado não é "privado", é compartilhado. Sim, mesmo com ACLs e tudo o que estiver em vigor. Existem diferenças técnicas também (obviamente, meu ramal privado do git é usado enquanto estou indo para casa, sem / Internet não confiável), mas são subsidiárias da diferença social.
tialaramex

2
Uma filial privada com forçosamente, é uma merda. A facilidade com que você cria e alterna entre branches no git não pode ser comparada com forçosamente. O quão privado é realmente um ramo "privado" forçado de qualquer maneira. Você não o mantém local. Você é totalmente dependente do acesso à rede.
Erik Engheim

9

O comando que me vendeu pessoalmente no git foi bisect . Não acho que esse recurso esteja disponível em qualquer outro sistema de controle de versão até agora.

Dito isso, se as pessoas estão acostumadas com um cliente GUI para controle de origem, elas não ficarão impressionadas com o git. No momento, o único cliente completo é a linha de comando.


1
Para ser justo (escolhi git em vez de Hg), deve-se observar que o Mercurial também tem capacidade de bissetriz - embora seja fornecido como um plugin que você precisa carregar explicitamente.
Aristóteles Pagaltzis,

2
darcs tem "trackdown" desde antes de o git existir. As primeiras versões eram bem grosseiras, é verdade.
wnoise

2
com relação à IU - GitX no OSX é excelente.
Antony Stubbs,

4
SourceTree também é outro bom cliente osx nativo. Tornou-se gratuito depois de adquirido. Já faz algum tempo que o uso e gosto dele. Eu era principalmente comandante antes de usar SourceTree.
Prakash Nadar

1
Na minha experiência com o Git, você realmente precisa da linha de comando e de um cliente gráfico para usá-lo de forma eficaz. Você precisa da linha de comando porque há muito poder que não é fácil de colocar em uma GUI, e você precisa da GUI (ou pelo menos git log --graph) porque os históricos de revisão do Git tendem a ser não lineares e difíceis de visualizar sem uma imagem. Eu uso GitX e SourceTree como GUIs, embora gitk (que vem com Git agora) seja passável em uma pitada.
Marnen Laibow-Koser

9

Quais recursos do Perforce as pessoas estão usando?

  • Vários espaços de trabalho em uma única máquina
  • Changelists numeradas
  • Ramos de desenvolvedor
  • Integração com IDE (Visual Studio, Eclipse, SlickEdit, ...)
  • Muitas variantes de construção
  • Espaços de trabalho compostos
  • Integrando algumas correções, mas não outras
  • etc

Eu pergunto porque se tudo que as pessoas estão fazendo é get e put a partir da linha de comando, o git cobre isso, e o mesmo acontece com todos os outros RTS.


2
Não tenho certeza sobre o que significa "vários espaços de trabalho em uma única máquina" - outros VCSs simplesmente não têm o conceito de um espaço de trabalho, então ele realmente não pode ser apresentado como um recurso do Perforce. Os outros fazem sentido, no entanto.
Billy ONeal

Exemplo de área de trabalho múltipla: o cliente A tem versões de desenvolvimento e lançamento de arquivos somente A mais um subconjunto de ferramentas internas na versão 1.52; o cliente B tem arquivos dev & release B-only mais um subconjunto diferente, mas sobreposto de ferramentas internas, ambos dev e versão 1.52. O desenvolvedor está trabalhando em ambos simultaneamente e pode optar por tornar as ferramentas internas alteradas visíveis para A para ver o que quebra.
Thomas L Holaday

6
@Tomas: Por que você não ... Basta verificar duas vezes? O Perforce precisa ter isso como um "recurso", caso contrário, fica estranho devido a ter que garantir que as variáveis ​​de ambiente estão definidas corretamente, as entradas de registro corretas, etc.
Arafangion

@Arafangion, não é óbvio como o check-out duas vezes facilita a exposição seletiva de arquivos para construir conjuntos.
Thomas L Holaday

6

Aparentemente, o GitHub agora oferece cursos de treinamento git para empresas . Quoth o post do blog deles sobre isso :

Estive no campus do Google várias vezes nas últimas semanas ajudando a treinar os Androids lá no Git. Fui convidado por Shawn Pearce (você deve conhecê-lo de sua glória Git e EGit / JGit - ele é o herói que assume a manutenção quando Junio ​​está fora da cidade) para ajudá-lo a treinar os engenheiros do Google que trabalham no Andriod na transição do Perforce ao Git , para que o Android pudesse ser compartilhado com as massas. Posso dizer que fiquei mais do que feliz em fazer isso.

[…]

O Logical Awesome está agora oferecendo oficialmente este tipo de serviço de treinamento personalizado para todas as empresas, onde podemos ajudar sua organização com treinamento e planejamento se você estiver pensando em mudar para Git também.

Ênfase minha.


4

Eu uso o Perforce há muito tempo e recentemente também comecei a usar o GIT. Aqui está minha opinião "objetiva":

Recursos do Perforce:

  1. As ferramentas da GUI parecem ser mais ricas em recursos (por exemplo, visualização de lapso de tempo, gráfico de revisão)
  2. Velocidade ao sincronizar com a revisão do cabeçote (sem sobrecarga de transferência de todo o histórico)
  3. A integração Eclipse / Visual Studio é muito boa
  4. Você pode desenvolver vários recursos em um branch por Changelist (ainda não tenho 100% de certeza se isso é uma vantagem sobre o GIT)
  5. Você pode "espiar" o que outros desenvolvedores estão fazendo - que tipo de arquivos eles retiraram.

Recursos do GIT:

  1. Tive a impressão de que a linha de comando GIT é muito mais simples do que Perforce (init / clone, adicionar, confirmar. Sem configuração de espaços de trabalho complexos)
  2. Velocidade ao acessar o histórico do projeto após um checkout (tem o custo de copiar todo o histórico durante a sincronização)
  3. Modo offline (os desenvolvedores não reclamarão que o servidor P4 inacessível os proibirá de codificar)
  4. Criar novos branches é muito mais rápido
  5. O servidor GIT "principal" não precisa de muitos TBytes de armazenamento, porque cada desenvolvedor pode ter sua própria sandbox local
  6. GIT é OpenSource - sem taxas de licenciamento
  7. Se sua empresa está contribuindo também para projetos OpenSource, compartilhar patches é muito mais fácil com o GIT

No geral para projetos OpenSource / Distributed eu sempre recomendaria o GIT, porque é mais parecido com uma aplicação P2P e todos podem participar do desenvolvimento. Por exemplo, eu lembro que quando eu estava fazendo desenvolvimento remoto com Perforce eu sincronizava Projetos de 4 GB em link de 1 Mbps uma vez por semana. Muito tempo foi simplesmente perdido por causa disso. Também precisamos configurar a VPN para fazer isso.

Se você tem uma empresa pequena e o servidor P4 está sempre ativo, eu diria que o Perforce também é uma opção muito boa.


O recurso nº 1 do Git é, na melhor das hipóteses, uma afirmação duvidosa. Talvez o Git ganhe na configuração, mas o uso do dia a dia é muito desajeitado (muitas vezes requer vários comandos para realizar uma tarefa simples)
Adam Parkin

1
@AdamParkin Que tarefas você acha desajeitadas na linha de comando? (Eu uso GUIs sempre que possível, mas acho que a estrutura de comando do Git é decente.)
Marnen Laibow-Koser

1
@AdamParkin Bem, a facilidade de usar a linha de comando é o aspecto estético, portanto, é subjetivo pelo menos. A razão pela qual eu pessoalmente considero a linha de comando do Git mais simples do que a do Perforce, é que no Perforce você deve configurar espaços de trabalho e variáveis ​​de ambiente (P4USER etc) antes mesmo de começar a trabalhar com os arquivos do repositório, em comparação com um único "clone do git" comando. Claro que existem alguns comandos git avançados que estão ausentes no Perforce (por exemplo, reescrever a história local) e eles podem parecer "ciência do foguete" para usuários regulares do Perforce.
user389238

Eu não usei isso, mas me parece que gerenciar conjuntos de mudanças é apenas um branch de um homem pobre, considerando que no git você pode esmagar seus branches de recursos ou realocá-los no master.
Ryan The Leach

4

Temos usado o Git por algum tempo, recentemente o disco rígido do nosso servidor Git travou e não foi possível reverter para o estado mais recente. Conseguimos voltar ao estado de poucos dias. Quando o servidor estava de volta. Todos na equipe puxaram / empurraram suas alterações e pronto, o servidor voltou ao estado atual.


3
Em uma palestra que Linus deu ao @ Google sobre Git, ele falou sobre como não faz backups, já que o clone de todo mundo do kernel do Linux é um backup completo dele. Ponto muito bom, na verdade.
Adam Parkin

Isso é verdade em todos os sentidos, cada fechamento é um "backup", mas o git em muitos casos ainda é usado como uma ferramenta "centralizada-distribuída". ou seja, como o SVN com benefícios adicionais de ramificação. A organização sempre quer um backup de tudo o que possui.
Prakash Nadar

3

A única diferença importante entre o Perforce e o git (e o mais comumente mencionado) é o respectivo manuseio de enormes arquivos binários.

Como, por exemplo, neste blog de um funcionário de uma empresa de desenvolvimento de videogame: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

No entanto, o importante é que, a diferença de velocidade entre git e perforce, quando você tem um enorme repositório de 6 GB, contendo tudo, desde a documentação até todos os binários já construídos (e finalmente, oh sim! O histórico de origem real), geralmente vem fato de que grandes empresas tendem a executar o Perforce e, portanto, configuram-no para descarregar todas as operações significativas para o enorme banco de servidores no porão.

Esta vantagem importante da parte do Perforce vem apenas de um fator que não tem nada a ver com o Perforce, o fato de que a empresa que o executa pode pagar o referido banco de servidores.

E, de qualquer forma, no final, Perforce e git são produtos diferentes. Git foi projetado para ser apenas um VCS, e faz isso muito melhor do que Perforce (no sentido de que tem mais recursos, que geralmente são mais fáceis de usar, em particular, nas palavras de outro, ramificar em Perforce é como executar o coração aberto cirurgia, só deve ser feita por especialistas: P) ( http://stevehanov.ca/blog/index.php?id=50 )

Quaisquer outros benefícios que as empresas que usam o Perforce ganham vêm simplesmente porque o Perforce não é apenas um VCS, é também um servidor de arquivos, além de ter uma série de outros recursos para testar o desempenho de compilações, etc.

Finalmente: sendo o Git de código aberto e muito mais flexível para inicializar, não seria tão difícil corrigir o git para descarregar operações importantes em um servidor central, executando montes de hardware caro.


3

Acho que a única coisa que sei que o GIT vence é a capacidade de "preservar terminações de linha" em todos os arquivos, ao passo que forçosamente parece insistir em traduzi-los para o formato Unix, Dos / Windows ou MacOS9 ("\ n", "\ r \ n "ou" \ r).

Isso é uma dor real se você estiver escrevendo scripts Unix em um ambiente Windows ou um ambiente de sistema operacional misto. Nem mesmo é possível definir a regra por extensão de arquivo. Por exemplo, ele converteria arquivos .sh, .bash, .unix para o formato Unix e converteria arquivos .ccp, .bat ou .com para o formato Dos / Windows.

No GIT (não tenho certeza se isso é padrão, uma opção ou a única opção), você pode configurá-lo para "preservar terminações de linha". Isso significa que você pode alterar manualmente as terminações de linha de um arquivo, e então o GIT deixará esse formato do jeito que está. Esta me parece a maneira ideal de fazer as coisas, e não entendo por que não é uma opção com o Perforce.

A única maneira de conseguir esse comportamento é marcar os arquivos como binários. A meu ver, seria um hack desagradável para contornar um recurso ausente. Além de ser entediante ter que fazer em todos os scripts, etc, provavelmente também quebraria a maioria dos diffs, etc.

A "solução" que decidimos no momento é executar um comando sed para remover todos os retornos de carro dos scripts sempre que eles forem implantados em seu ambiente Unix. Isso também não é o ideal, especialmente porque alguns deles são implantados dentro de arquivos WAR e a linha sed precisa ser executada novamente quando são descompactados.

Isso é apenas algo que eu acho que dá ao GIT uma grande vantagem, e que eu não acho que tenha sido mencionado acima.

EDITAR: Depois de usar o Perforce por mais um tempo, gostaria de adicionar mais alguns comentários:

A) Algo que eu realmente sinto falta no Perforce é um diff claro e de instância, incluindo arquivos alterados, removidos e adicionados. Isso está disponível no GIT com ogit diff comando, mas no Perforce, os arquivos devem ser verificados antes de suas alterações serem gravadas, e embora você possa ter seus editores principais (como o Eclipse) configurados para verificar automaticamente os arquivos ao editá-los, você pode às vezes editar arquivos de outras maneiras (bloco de notas, comandos unix, etc). E novos arquivos não parecem ser adicionados automaticamente, mesmo usando Eclipse e p4eclipse, o que pode ser um tanto chato. Portanto, para encontrar todas as alterações, você deve executar uma "Diferença contra ..." em todo o espaço de trabalho, o que, em primeiro lugar, leva um tempo para ser executado e, em segundo lugar, inclui todo o tipo de coisas irrelevantes, a menos que você configure listas de exclusão muito complicadas, o que me leva ao próximo ponto.

B) No GIT, acho o .gitignore muito simples e fácil de gerenciar, ler e entender. No entanto, as listas de ignorar / excluir do espaço de trabalho configuráveis ​​no Perforce parecem pesadas e desnecessariamente complexas. Não consegui obter nenhuma exclusão com caracteres curinga funcionando. Eu gostaria de fazer algo como

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

Para excluir todas as pastas de destino em todos os projetos dentro do Server / mainline. No entanto, isso não parece funcionar como eu esperava, e acabei adicionando uma linha para cada projeto como:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

E linhas semelhantes para pastas bin, arquivos .classpath e .projet e muito mais.

C) No Perforce, existem as changelists bastante úteis. No entanto, suponha que eu faça um grupo de alterações, verifico todas e coloco em uma changelist, para então trabalhar em outra coisa antes de enviar essa changelist. Se eu mais tarde fizer uma alteração em um dos arquivos incluídos na primeira changelist, esse arquivo ainda estará naquela changelist, e eu não posso enviar a changelist posteriormente presumindo que ela contém apenas as alterações que eu adicionei originalmente (embora serão os mesmos arquivos). No GIT, se você adicionar um arquivo e eles fizerem outras alterações nele, essas alterações não serão adicionadas (e ainda apareceriam em umgit diffe você não seria capaz de confirmar o arquivo sem primeiro adicionar as novas alterações também. Claro, isso não é útil da mesma forma que a lista de alterações pode ser, já que você só tem um conjunto de arquivos adicionados, mas no GIT você pode apenas enviar as alterações, já que isso não as empurra de fato. Você poderia trabalhar em outras alterações antes de enviá-los, mas não seria capaz de enviar qualquer outra coisa que você adicionasse posteriormente, sem enviar também as alterações anteriores.


2

Não tenho experiência com Git, mas tenho com Mercurial que também é um VCS distribuído. Na verdade, depende do projeto, mas em nosso caso um VCS distribuído se adequou ao projeto, pois basicamente eliminou compilações quebradas frequentes.

Acho que depende muito do projeto, pois alguns são mais adequados para um VCS cliente-servidor e outros para um distribuído.


(Concedido, esta é uma resposta antiga, mas ...) Você pode executar o Git (e presumo também o Mercurial) como se fosse um VCS cliente-servidor. Ele ainda funciona melhor do que VCSs cliente-servidor, devido à facilidade de ramificação e fusão e à possibilidade de commits privados. Não vejo mais muita utilidade para VCSs cliente-servidor, pelo menos até que eles alcancem suas habilidades de mesclagem.
Marnen Laibow-Koser

-5

Aqui está o que eu não gosto no git:

Em primeiro lugar, acho que a ideia distribuída vai contra a realidade. Todos que realmente usam o git o fazem de forma centralizada, até mesmo Linus Torvalds. Se o kernel foi gerenciado de forma distribuída, isso significaria que eu não poderia realmente baixar as fontes "oficiais" do kernel - não haveria uma - eu teria que decidir se eu quero a versão de Linus ou a versão de Joe, ou a versão de Bill. Isso seria obviamente ridículo, e é por isso que existe uma definição oficial que Linus controla usando um fluxo de trabalho centralizado.

Se você aceitar que deseja uma definição centralizada de suas coisas, ficará claro que as funções de servidor e cliente são completamente diferentes, de modo que o dogma de que os softwares de cliente e servidor devem ser iguais torna-se puramente limitante. O dogma de que os dados do cliente e do servidor devem ser iguais torna-se patentemente ridículo, especialmente em uma base de código que tem quinze anos de história com a qual ninguém se importa, mas que todos teriam que clonar.

O que realmente queremos fazer com todo aquele material antigo é enfiá-lo em um armário e esquecer que está lá, como qualquer VCS normal faz. O fato de o git transportar tudo para a frente e para trás pela rede todos os dias é muito perigoso, porque te incomoda para podá-lo. Essa poda envolve muitas decisões tediosas e pode dar errado. Portanto, as pessoas provavelmente manterão toda uma série de repositórios de instantâneos de vários pontos da história, mas não era para isso que servia o controle de origem? Esse problema não existia até que alguém inventou o modelo distribuído.

O Git incentiva ativamente as pessoas a reescrever a história, e o que está acima é provavelmente um dos motivos para isso. Todo VCS normal torna a reescrita do histórico impossível para todos, exceto os administradores, e garante que os administradores não tenham razão para considerá-lo. Corrija-me se eu estiver errado, mas pelo que eu sei, git não oferece nenhuma maneira de conceder aos usuários normais acesso de gravação, mas bani-los de reescrever o histórico. Isso significa que qualquer desenvolvedor com ressentimento (ou que ainda está lutando com a curva de aprendizado) pode destruir toda a base de código. Como podemos apertar esse? Bem, ou você faz backups regulares de todo o histórico, ou seja, mantém o histórico ao quadrado, ou bane o acesso de gravação a todos, exceto a alguns pobres coitados que receberiam todos os diffs por e-mail e os mesclaria manualmente.

Vamos dar um exemplo de um grande projeto bem financiado e ver como o git está funcionando para eles: Android. Certa vez, decidi brincar com o próprio sistema Android. Eu descobri que deveria usar um monte de scripts chamados repo para chegar ao git. Alguns repo são executados no cliente e outros no servidor, mas ambos, por sua própria existência, estão ilustrando o fato de que o git está incompleto em ambas as capacidades. O que aconteceu é que não consegui obter as fontes por cerca de uma semana e desisti de vez. Eu teria que extrair uma quantidade verdadeiramente vasta de dados de vários repositórios diferentes, mas o servidor estava completamente sobrecarregado com pessoas como eu. O repo estava expirando e não foi possível retomar de onde havia expirado. Se o git é tão distribuível, você pensaria que eles ' d teria feito algum tipo de coisa ponto a ponto para aliviar a carga naquele servidor. Git é distribuível, mas não é um servidor. Git + repo é um servidor, mas repo não é distribuível porque é apenas uma coleção ad-hoc de hacks.

Uma ilustração semelhante da inadequação do git é o gitolite (e seu ancestral, que aparentemente não funcionou tão bem). Gitolite descreve seu trabalho como facilitar a implantação de um servidor git. Novamente, a própria existência dessa coisa prova que git não é um servidor, assim como não é um cliente. Além do mais, nunca será, porque se se transformasse em qualquer um deles estaria traindo seus princípios fundamentais.

Mesmo se você acreditasse na coisa distribuída, o git ainda seria uma bagunça. O que, por exemplo, é um galho? Eles dizem que você cria implicitamente um branch cada vez que clona um repositório, mas isso não pode ser a mesma coisa que um branch em um único repositório. Portanto, pelo menos duas coisas diferentes são chamadas de branches. Mas então, você também pode retroceder em um repositório e simplesmente começar a editar. É como o segundo tipo de branch ou algo diferente de novo? Talvez dependa do tipo de repo que você tem - ah, sim - aparentemente, o repo também não é um conceito muito claro. Existem normais e normais. Você não pode empurrar para um normal porque a parte vazia pode ficar fora de sincronia com sua árvore de origem. Mas você não pode cvsimportar para um só porque eles não pensaram nisso. Então você tem que cvsimport para um normal, clone isso para um arquivo vazio que os desenvolvedores acertaram e cvsexport para uma cópia de trabalho cvs que ainda precisa ser verificada no cvs. Quem pode ser incomodado? De onde vieram todas essas complicações? Da própria ideia distribuída. Abandonei o gitolite no final porque ele estava me impondo ainda mais dessas restrições.

Git diz que a ramificação deve ser leve, mas muitas empresas já têm um sério problema de ramificação desonesta, então eu pensei que a ramificação deveria ser uma decisão importante com policiamento estrito. É aqui que realmente brilha ...

Forçosamente, você raramente precisa de branches porque pode manipular changesets de uma maneira muito ágil. Por exemplo, o fluxo de trabalho normal é sincronizar com a última versão válida conhecida na linha principal e, em seguida, escrever seu recurso. Sempre que você tenta modificar um arquivo, o diff desse arquivo é adicionado ao seu "conjunto de alterações padrão". Quando você tenta fazer o check-in do changeset, ele automaticamente tenta mesclar as notícias da linha principal em seu changeset (efetivamente rebasando-o) e então se compromete. Esse fluxo de trabalho é aplicado sem que você precise entendê-lo. Dessa forma, a Mainline coleta um histórico de mudanças que você pode facilmente escolher mais tarde. Por exemplo, suponha que você queira reverter um antigo, digamos, aquele que antecede o penúltimo. Você sincroniza com o momento anterior à alteração ofensiva, marca os arquivos afetados como parte do conjunto de alterações, sincronizar com o momento seguinte e mesclar com "sempre meu". (Havia algo muito interessante lá: sincronizar não significa ter a mesma coisa - se um arquivo for editável (ou seja, em um changeset ativo), ele não será prejudicado pela sincronização, mas marcado como devido para resolução.) Agora você tem um changelist que desfaz o ofensivo. Junte-se às notícias subsequentes e você terá uma lista de mudanças que pode colocar no topo da linha principal para ter o efeito desejado. Em nenhum momento reescrevemos qualquer história. Junte-se às notícias subsequentes e você terá uma lista de mudanças que pode plopar no topo da linha principal para ter o efeito desejado. Em nenhum momento reescrevemos qualquer história. Junte-se às notícias subsequentes e você terá uma lista de mudanças que pode colocar no topo da linha principal para ter o efeito desejado. Em nenhum momento reescrevemos qualquer história.

Agora, supondo que no meio do processo, alguém venha até você e diga para você largar tudo e consertar algum bug. Basta dar um nome à sua lista de alterações padrão (na verdade, um número) e então "suspendê-la", consertar o bug na lista de alterações padrão agora vazia, confirmá-la e retomar a lista de alterações nomeada. É comum ter vários changelists suspensos ao mesmo tempo em que você tenta coisas diferentes. É fácil e privado. Você consegue o que realmente deseja de um regime de filial sem a tentação de procrastinar ou evitar a fusão com a linha principal.

Suponho que seria teoricamente possível fazer algo semelhante no git, mas o git torna praticamente tudo possível ao invés de afirmar um fluxo de trabalho que aprovamos. O modelo centralizado é um monte de simplificações válidas em relação ao modelo distribuído, o que é uma generalização inválida. Ele é tão generalizado que basicamente espera que você implemente o controle de origem, como o repo faz.

A outra coisa é a replicação. No git, tudo é possível, então você tem que descobrir por si mesmo. Forçosamente, você obtém um cache eficaz sem estado. A única configuração que ele precisa saber é onde está o mestre, e os clientes podem apontar para o mestre ou para o cache a seu critério. Isso é um trabalho de cinco minutos e não pode dar errado.

Você também tem gatilhos e formulários personalizáveis ​​para avaliar revisões de código, referências de bugzilla etc. e, claro, tem branches para quando realmente precisar deles. Não é claro, mas está perto e é muito fácil de configurar e manter.

Em suma, acho que se você sabe que vai trabalhar de forma centralizada, o que todo mundo faz, é melhor usar uma ferramenta que foi projetada com isso em mente. Git é superestimado por causa da sagacidade temível de Linus junto com a tendência das pessoas de seguirem umas às outras como ovelhas, mas sua principal razão de ser não resiste ao bom senso e, ao segui-lo, git amarra suas próprias mãos com os dois grandes dogmas de que (a) o software e (b) os dados têm que ser os mesmos tanto no cliente quanto no servidor, e isso sempre tornará tudo complicado e coxo no trabalho centralizado.


4
Oh, que diabos. Tenho alguns minutos, então tentarei comentar alguns dos erros maiores. "Se o kernel foi gerenciado de forma distribuída, isso significaria que eu não poderia realmente baixar as fontes" oficiais "do kernel - não haveria uma - eu teria que decidir se eu quero a versão de Linus ou a versão de Joe , ou a versão do Bill. "- Não posso falar especificamente sobre o projeto do kernel do Linux, já que nunca trabalhei nele, mas, em geral, é assim que o software de código aberto funciona. Você pode baixar qualquer fork que quiser.
Marnen Laibow-Koser

2
"O que realmente queremos fazer com todas essas coisas antigas é colocá-las em um armário e esquecer que está lá, assim como qualquer VCS normal faz. O fato de que o git carrega tudo para frente e para trás pela rede todos os dias é muito perigoso, porque te incomoda para podá-lo. " • Você já usou o Git? O Git não o incita a podar seu repo. Além disso, a compressão de dados do Git é extremamente eficiente; não é incomum que um repositório Git - com histórico de branch complexo - seja significativamente menor do que uma cópia de trabalho SVN (sem histórico) da mesma base de código.
Marnen Laibow-Koser

4
"Todo VCS normal torna a reescrita do histórico impossível para todos, exceto os administradores, e garante que os administradores não tenham motivos para considerá-lo. Corrija-me se eu estiver errado, mas pelo que eu sei, o git não oferece nenhuma maneira de permitir que usuários normais escrevam acessar, mas proibi-los de reescrever o histórico. Isso significa que qualquer desenvolvedor com ressentimento (ou que ainda estava lutando com a curva de aprendizado) pode destruir todo o código-base. " • Você está 100% errado. É fácil proibir push-push para o repo e, ao mesmo tempo, permitir acesso de gravação. Além disso, todos podem ter uma cópia do repositório que quiserem, portanto, o lixo não funcionaria.
Marnen Laibow-Koser

3
"Git diz que a ramificação deve ser leve, mas muitas empresas já têm um sério problema de ramificação desonesta, então eu pensei que a ramificação deveria ser uma decisão importante com policiamento estrito. É aqui que realmente brilha ..." • O que é um "problema de ramo desonesto"? Por que você acha que a ramificação deve ser uma "decisão importante"? Na prática, é muito útil poder criar branches (privados ou públicos) para cada novo recurso ou experimento, de modo que cada um viva em seu próprio universo alternativo. Ao contrário, digamos, do SVN, o Git facilita a fusão para que funcione muito bem.
Marnen Laibow-Koser

3
O fato de esta resposta ter apenas um downvote além da minha (aparentemente @Marnen) me surpreende, dado o quão objetivamente errada esta resposta é.
alternativa de

-8

Usar o GIT como substituto para o gerenciamento de linha de código ruim é comum. Muitas das desvantagens do Perforce são resultado de estratégias de ramificação ruins. O mesmo para qualquer outra ferramenta centralizada. Se você tiver que criar uma tonelada de branches, você está fazendo algo errado. Por que os desenvolvedores precisam criar tantos branches?

Além disso, por que trabalhar desconectado é tão importante? Só para alguém trabalhar em um trem? Esse é praticamente o único lugar hoje em dia em que você não consegue uma conexão sem fio. E até mesmo a maioria dos trens tem WiFi decente.


9
Alguns desenvolvedores gostam de criar branches para que possam facilmente isolar e segmentar diferentes desenvolvimentos, protótipos, correções de bugs, etc. Geralmente depende do tipo de trabalho. Os branches do Perforce são bastante pesados ​​para gerenciar em comparação com os branches do Git e Mercurial, e portanto, pode haver algumas melhorias de produtividade genuínas a serem feitas.
Greg Whitfield,

8
A capacidade de trabalhar desconectado nem sempre está relacionada à ideia de trabalhar em um trem ou avião. Algumas empresas podem não ter uma infraestrutura de rede confiável. Ou você pode obter interrupções, manutenção do servidor, interrupções gerais etc. Mas o efeito colateral de ser capaz de trabalhar desconectado é que suas operações de controle de origem são incrivelmente rápidas em comparação com sistemas que dependem de uma viagem de ida e volta da rede para fazer qualquer coisa.
Greg Whitfield,

6
Em minha experiência, usar o processo para controlar as pessoas é indicativo de um projeto de fluxo de trabalho ruim em primeiro lugar. Deve existir um fluxo de trabalho para manter as pessoas produtivas. Se não está sendo usado, há algo de errado com ele, porque em geral as pessoas não são idiotas e usarão uma ferramenta melhor se a encontrarem.
Carl de

6
Downvoting por causa de "Se você tiver que criar uma tonelada de branches, você está fazendo algo errado." Isso pode ser verdade em um VCS centralizado com ferramentas de mesclagem inadequadas (como SVN ou CVS - nunca usei o Perforce). Isso não é verdade no Git, onde ramificar e mesclar são fáceis e comuns. Isso dá a liberdade para cada recurso em desenvolvimento estar em seu próprio universo alternativo até a integração. Pessoalmente, eu nunca voltaria para um ambiente onde não pudesse ramificar por capricho.
Marnen Laibow-Koser
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.