Por que grandes empresas usam o Perforce? [fechadas]

Ouvi falar de algumas grandes empresas, por exemplo, Google, Facebook e Perforce.

Existe alguma razão pela qual o SVN / Git não pode substituir o Perforce?

A justificativa talvez seja menos relevante do que era antes, mas o Perforce tende a ter um desempenho melhor em repositórios grandes que o Subversion. Esse é um dos motivos pelos quais a Microsoft adquiriu uma licença de origem para o Perforce para construir o Source Depot; O repositório do NT é um monstro, e poucos produtos, comerciais ou outros, poderiam lidar com isso.

Além disso, pelo menos ao mesmo tempo, as ferramentas visuais do Perforce eram bem melhores do que as disponíveis imediatamente (por assim dizer) com o Subversion ou o Git. Se você estiver usando Meld, talvez essas coisas importem menos do que antes, mas ainda há algumas coisas que o Perforce fez muito bem, incluindo visualizações de ramificação e fusão das quais, embora eu não tenha uma memória detalhada desde que foi cerca de três anos desde que eu toquei o Perforce pela última vez, parecia mais sofisticado do que, por exemplo, a abordagem do Github a esse respeito.

Depois de usar o Perforce, você poderá entender quais são suas vantagens na prática. Há muito tempo, eles oferecem uma opção gratuita de servidor para dois usuários e, dependendo dos sistemas de gerenciamento de código-fonte com os quais você tem experiência, pode ser que valha a pena o custo da atualização depois que sua equipe testar por um tempo. Para lojas menores, isso, mais os efeitos de rede dos desenvolvedores que usaram e gostaram, são o motivo pelo qual o Perforce acaba recebendo usuários pagantes. Provavelmente, não há muito o que comer e vender de CTOs para vender o Perforce em empresas com pequenas equipes de desenvolvimento, em contraste com as observações cínicas de Dmitri, mas é usado em tais lugares.

A maioria dos projetos em que trabalhei fora da Microsoft pode ser razoavelmente bem atendida pelo Git, Mercurial ou Subversion, e eu diria que a maioria das empresas nas quais trabalhei utilizou uma dessas opções. Mas há um ponto ideal, geralmente uma combinação de tamanho de repositório, modelo de ramificação e mesclagem e experiência / histórico da equipe que leva as pessoas a usar ferramentas comerciais. Eu raramente vi grandes repositórios Git, por exemplo. Isso pode não ser devido a quaisquer limitações intrínsecas do Git; Eu admito total ignorância disso. Mas em alguns projetos (como o Windows NT), pode haver alguns limites práticos para soluções gratuitas.

Sou razoavelmente proficiente com svn, git e Perforce, tanto como usuário quanto na configuração e manutenção de servidores.

Para uma empresa, ou mesmo um programador solitário como eu, o controle de origem é um custo incorrido no suporte à atividade real de ganhar dinheiro, que está desenvolvendo e vendendo código. Portanto, há vários fatores a serem considerados:

• Quão bem ele se encaixa no seu modelo de desenvolvimento?
• Quão fácil é para os desenvolvedores aprenderem e usarem?
• As operações de rotina para os desenvolvedores são rápidas?
• O processo de usá-lo é uma distração de seu trabalho real, que é escrever código?
• Quão fácil é configurar e manter?
• Quanto custa comprar e manter?
• Se você precisar de ajuda, como é fácil obtê-lo?

Vou pular os detalhes do tl: dr sobre os prós e os contras dos sistemas individuais. Basta dizer que, quando voltei à consultoria em tempo integral no ano passado, revisei os três para decidir o que me permitiria ganhar o máximo de dinheiro o mais rápido possível, entregando software de qualidade aos meus clientes e sem exigir muito dinheiro não remunerado. brincando. Quando tomei a consideração política de "FOSS é bom e não-FOSS é mau" fora da equação, acabei procurando uma licença Perforce.

E é por isso que as grandes empresas escolhem o Perforce também.

Aqui estão os detalhes tl: dr dos comentários, além de um pouco mais.

Lidar com o svn é fácil: comparado ao Perforce, é muito lento. Eu trabalhei em uma empresa que incorporou Linux para telefones celulares e nossas fontes completas rodavam 9 GB; eles usaram o Perforce. Depois de ter o código, a atualização das fontes mais recentes normalmente levava segundos na LAN ou alguns minutos em uma conexão VPN da minha casa. Com o svn, seriam minutos e horas, respectivamente.

git vs. Perforce é mais complicado. Muitas empresas acham que têm boas razões comerciais para usar um repositório centralizado com controle de acesso e para facilitar o comprometimento e a execução de qualquer outra coisa - e o Perforce se encaixa perfeitamente nesse modelo. No entanto, o git incentiva positivamente as pessoas a trabalhar em uma filial local e não há como fazê-lo funcionar de maneira diferente. Um desenvolvedor pode trabalhar inteiramente em uma filial local e nunca se comprometer com o repositório central - portanto, se uma empresa não deseja que seu pessoal trabalhe dessa maneira, o Perforce é uma opção melhor.

Existem outros problemas com o git para algumas necessidades de negócios. Eu trabalhei em uma empresa que usava git e não sei quantas vezes ouvi essa discussão: "Gostaria que estivéssemos usando [alguns outros VCS], porque preciso fazer [isso] e não posso com o git . " "Claro que você pode fazer isso com o git." "Como?" "Bem, primeiro você precisa escrever um script bash ..." "Não importa."

E ainda há o tempo necessário para preencher inicialmente uma árvore de origem com muito histórico. Com o Perforce, como o histórico é mantido no servidor, você obtém as versões mais recentes de todos os arquivos, por isso é muito rápido - até a configuração de toda a árvore de 9 GB que mencionei levou apenas algumas horas em uma VPN. Com o git, pode levar algum tempo entre um longo período e uma eternidade. Às vezes, eu tenho que clonar o GTK + ou o Git Repos do servidor X, e isso é uma longa pausa para o almoço, ou talvez seja hora de dormir.

Realmente, é uma questão da ferramenta certa para o trabalho. O svn funciona bem para a maioria dos esforços de código aberto da Apple e seria péssimo para hackers de kernel. O git funciona muito bem no GTK +, mas é incrivelmente lento para trabalhar no WebKit - a árvore e o histórico da fonte são enormes demais (como descobri da maneira mais difícil trabalhar com código do portal svn-to-git do WebKit). O Perforce funciona bem se você possui uma árvore de origem gigante e precisa de controle centralizado. Cada um deles funciona bem no contexto certo.

O GIT, especialmente, e o SVN, até certo ponto, não são tão antigos - se você precisava de um controle sólido de versão em meados dos anos 90, quase precisava comercializar, pois o SVN estava em sua infância e o CVS era, assim, o CVS. Depois de investir muito em um sistema, movê-lo pode ser um urso.

Ah, e os funcionários que tomam essas decisões provavelmente nunca interagem com o sistema de controle de versão, mas são atraídos e jantados pela equipe de vendas mencionada acima.

Sou programador na indústria de jogos há quase 9 anos e todos os projetos em que trabalhei utilizaram o Perforce. Suspeito que existam algumas coisas que mantêm o Perforce em uso nesse setor em particular.

• As pessoas usam o Perforce há muito tempo e se sentem bem com ele, hesitando em mudar para outra solução. Os tomadores de decisão também podem hesitar em colocar seu projeto de 30 milhões de dólares nas mãos de software que nunca usaram antes.
• Muitas empresas / equipes adicionaram o suporte do Perforce às suas ferramentas internas, o que pode exigir uma quantidade significativa de trabalho para ser atualizado para dar suporte a outro VCS.
• Embora os programadores possam ter facilidade em mudar para outro Git / Hg / SVN, há muitos membros menos técnicos de uma equipe de desenvolvimento de jogos, como artistas, designers e produtores. Conseguir que eles se sintam confortáveis ​​com o novo sistema pode levar muito tempo, e eu gostaria de apostar que eles seriam bastante resistentes à mudança.

Talvez, talvez eles gostem do Perforce porque o Perforce é melhor?

• Perforce é rápido. Muito mais rápido que o Subversion ou o Git.
• A fusão forçada é melhor que o Subversion ou o Git. O Git realmente não mescla e o rastreamento de versão do Subversion não é tão bom, pelo menos na versão 1.5.
• O Perforce possui excelente suporte ao cliente.
• O Perforce combina a revisão de repositório do Subversion com revisões de arquivos individuais. O Perforce permite visualizar revisões do repositório por meio de listas de alterações ou revisões de arquivos individuais.
• O Perforce faz um trabalho muito melhor com várias listas de alterações do que o Subversion. As listas de alterações do Subversion são uma espécie de reflexão tardia e eu conheço poucos que a usam. O Perforce está embutido. Se você mover um arquivo alterado da lista de alterações padrão, ele não será confirmado acidentalmente.
• O Perforce permite que você especifique seu layout de diretório de trabalho. Por exemplo, se você tiver uma árvore de diretórios de código-fonte padrão, mas alguns clientes tiverem uma fonte personalizada, poderá sobrepor a fonte personalizada sobre a árvore padrão. Você pode fazer checkouts esparsos com facilidade, especificando apenas os itens que deseja fazer o checkout.

Ok, antes que você pense que sou fã do Perforce, a última vez que recomendei o Perforce para uma empresa foi há mais de sete anos. O Perforce custa US $ 800 por licença - o que é barato comparado ao ClearCase, mas muito caro quando comparado ao Subversion. É difícil justificar o Perforce sobre o Subversion.

Além disso, a maioria dos desenvolvedores está acostumada ao Subversion. Eles não querem aprender o Perforce, que tem uma maneira diferente de trabalhar que o Subversion. No Perforce, você precisa criar um cliente e marcar os arquivos para edição antes de poder modificá-los. Você não precisa fazer isso com o Subversion.

Também há menos integrações com o Perforce over Subversion. Parte disso é devido ao uso do cliente . Simplesmente não funciona bem com o VisualStudio ou mesmo com o Hudson. Parte disso se deve ao fato de o Perforce precisar criar as integrações do cliente.

Há um custo para a licença proprietária chamar o custo administrativo. Imagine se você pudesse licenciar um software por US $ 1,00 por usuário. Caramba, vamos fazer dois bits. Milhares de licenças custariam apenas US $ 250.

Agora, você precisa de uma pessoa em tempo integral gerenciando a licença. Um trabalhador técnico médio fica em uma empresa por cerca de 2 anos. Isso significa que 500 pessoas por ano partirão e outras 500 virão. Dez pessoas a cada semana precisam mudar a licença. Então, há momentos em que o projeto é iniciado e você precisa de outras 250 licenças. Esses devem ser pedidos, inseridos e mantidos. Isso pode levar semanas.

É por isso que muitas empresas comerciais mudaram para o código aberto. Não é o custo de uma licença. Você paga a um desenvolvedor US $ 150.000 por ano, o que significa outros US $ 800 por uma licença Perforce? Está gerenciando essa licença. O Perforce parece ótimo quando comparado ao ClearCase: mais rápido, mais fácil, mais barato, melhor. Mas contra o Subversion? O Forforce pode ser mais rápido e talvez melhor, mas é US $ 800 melhor? Está gerenciando a licença melhor? Não está usando melhor a ferramenta desejada?

É por isso que o Perforce pode estar tendo problemas.

O Git não é a ferramenta completa. Funciona muito bem em circunstâncias em que você não deseja controle centralizado de quem tem acesso a um repositório. Mas, pode ser uma dor em muitas circunstâncias. A maneira como eu coloco é desta forma:

1. Você executa um projeto de código aberto. Você ficaria feliz ou chateado se um milhão de pessoas tivesse uma cópia de todo o seu repositório?
2. Você está executando uma mesa de negociação financeira que usa software proprietário para obter uma vantagem sobre seus concorrentes. Você ficaria feliz ou chateado se um milhão de pessoas tivesse uma cópia de todo o seu repositório?

Se você estiver criando compilações centralizadas, precisará que todos usem um único repositório de qualquer maneira. Qual é a vantagem de um sistema distribuído nessa circunstância? De fato, isso pode incentivar as pessoas a trabalharem off-line . Os desenvolvedores podem simplesmente seguir seu próprio caminho alegre e não cometer nada até o último minuto. Então, você passa dois dias frenéticos tentando fazer tudo funcionar novamente.

Eu não sou contra Git. Eu recomendo o Git em muitos casos. Isso inclui equipes distribuídas com conexões ruins entre si ou locais onde você não deseja rastrear todos que têm acesso ao repositório de origem.

Por exemplo, um departamento de ciência da computação da faculdade queria que seus alunos usassem o controle de origem e colocasse seu código lá para os professores verem. Boa ideia. Muitas crianças saem da faculdade sem entender os procedimentos padrão de construção e desenvolvimento. Eu recomendei o Git.

Usando o Git, o administrador do repositório só precisa aceitar confirmações de seus colegas professores. Eles não precisam se preocupar com os alunos individualmente. Os professores podem permitir que os alunos se comprometam com sua versão do repositório. Os alunos podem trabalhar em grupos e cada grupo pode compartilhar sua versão do repositório.

Se a faculdade usasse o Subversion, alguém teria que conhecer todos os alunos e dar a todos acesso ao repositório central. Eles teriam que gerenciar quem pode verificar o que e onde. Se um professor designasse um projeto de grupo, isso teria que ser configurado e gerenciado. Você precisaria de uma pessoa em período integral apenas para gerenciar isso.

Este não é um jogo de futebol em que um time é melhor que outro. As ferramentas funcionam de maneiras diferentes e cada uma tem suas vantagens e desvantagens. O Perforce é uma ótima ferramenta. Infelizmente, surgiram circunstâncias que dificultam a recomendação.

O Git é ótimo, mas continuo recorrendo ao Subversion para o meu repositório de fontes pessoais. Afinal, eu não compartilho, e o Subversion é apenas mais fácil de usar. Uso o Git para trabalho pessoal se tiver uma equipe pequena, porque não preciso manter meu repositório em tempo integral na Internet. Para a maioria dos sites comerciais, ainda acho que o Subversion funciona melhor. Mas há circunstâncias em que o Git brilha.

Não sei se o suborno 'vinho e jantar' ainda é aplicável, mas para a maioria dos gerentes quando decidirem encontrar um produto, eles lerão em várias publicações (direcionadas à gerência) e olharão os folhetos e panfletos que exaltam o produto. virtudes.

Adivinha o quê, os produtos FOSS não aparecem nesses lugares!

Portanto, é quase certo que a maioria das decisões de compra de gerenciamento seja conduzida por publicidade e marketing. Eles podem realizar avaliações, mas de vários desses produtos.

O outro motivo é devido ao vencimento. Alguns produtos que usamos hoje são estáveis ​​apenas o suficiente para uso comercial sério, alguns não têm opções de suporte, outros não têm histórico comprovado de solução comercial. Essas são coisas importantes a considerar (embora, como técnico, eu avaliarei com satisfação as soluções de software livre, se o risco de usá-las e de fazê-las falhar for mínimo para manter os negócios funcionando) e alguns gerentes são cautelosos em não tê-las por perto. Eles são responsáveis ​​perante os chefes e se sentirão muito mais confortáveis ​​se houver uma organização de suporte por trás do produto - afinal, você tem uma para a sua empresa.

Por fim, embora muitos produtos FOSS tenham suporte (pense em Collabnet ou Wandisco para SVN), ele ainda recebe a reputação de 'feito por geeks no quarto dos fundos'. Nós todos sabemos que é geralmente b * * ** t ea melhor FOSS compete incrivelmente bem com ofertas comerciais, mas meu gerente ainda precisa ser convencido. talvez ele simplesmente não perceba a diferença entre os produtos imaturos e maduros do software livre; talvez ele não se importe.

De qualquer forma, o Perforce é um excelente SCM, não há razão para não escolher. Eu poderia dizer o mesmo para outros SCMs, mas, novamente, só posso dizer coisas ruins sobre alguns outros, e ainda ter pesadelos quando se trata de um determinado par de produtos.

Porque ferramentas como a Perforce têm vendedores para degustar e jantar pessoas encarregadas de comprar, enquanto o Git não. Claro, esse é apenas o lado cínico de mim falando, mas é um cinismo causado por ver o processo de perto.

Apenas para deixar perfeitamente claro: não quero dizer que toda vez que você vir seu CIO tropeçando bêbado pelo corredor, espere usar um novo sistema de versão no próximo trimestre. Só que há uma desconexão em muitas organizações entre uso e aquisição. É claro que existem outras razões pelas quais as empresas usam o Perforce: por exemplo, elas já podem ter investido fortemente em sua implementação em seu fluxo de trabalho. Mas geralmente --- e essa pergunta é muito geral --- não há vantagem funcional em não usar as ferramentas do FOSS.

Provavelmente, a mesma razão pela qual minha empresa se recusa a usar muitos softwares de código aberto (não que eu concorde):

Quando algo dá errado, eles querem alguém para quem possam ligar e gritar.

Embora todas as respostas falem sobre grandes empresas usando o P4 (e elas respondem por que o Google usou o P4), um dos principais motivos pelos quais o Google continua a usar o Perforce é que o Perforce permite que você faça check-out de uma subárvore do repositório, enquanto não pode fazer isso com o Git. Com repositórios de fontes grandes como os do Google, isso fez uma enorme diferença.

E até onde eu ouvi, o Facebook usa SVN e Git-SVN

Como o SVN é, bem, o SVN e o Perforce (desde os 4 anos anteriores ao comparar ferramentas) faz algumas coisas melhor que o SVN . (Ramificação é uma delas, eu acho.)

E o GIT é um Dvcs, como no distribuído . Para as equipes da empresa, a peça distribuída pode muito bem ser algo que nem se importa nem se deseja.

Outra razão pela qual as grandes empresas tendem a comprar grandes sistemas de controle de versão "corporativos", desajeitados:

A gerência de nível intermediário até o superior nos departamentos de TI vê o VCS como algo que todo projeto usa, ou você pode aplicá-lo. Depois de impor o uso de um VCS, por que não colocar um pequeno "processo" também? Quero dizer, você tem a oportunidade de especificar um sistema "em toda a empresa", por que não colocá-lo sob controle central e adicionar "recuperação de desastre" e alguns "recursos de fluxo de trabalho" para poder dizer "Somos uma camisa reta de nível CMM" compatível!". Um VCS é um alvo fácil demais para colocar os recursos que impõem o fluxo de trabalho.

No que diz respeito à escolha de algum software grosseiro (Serena Dimensions), diz-se que algumas rodadas de Bikini Golf nas Bahamas com algumas 20 ou mais equipes de vendas podem convencer um diretor ou vice-presidente de praticamente qualquer coisa.

As grandes empresas precisam de um modelo centralizado de algum tipo. Depois que os desenvolvedores terminam o desenvolvimento, eles são entregues ao suporte ao cliente. Deseja realmente usar sapatos de suporte quando eles precisam vasculhar 50 a 200 repos distribuídos por desenvolvedores? E as compilações são feitas com base no repositório central, as compilações devem sempre, sempre, sempre ser rastreáveis ​​e reproduzíveis. Você aprende isso na primeira vez em que é levado a tribunal por alguma violação boba de patente.

O Git não funciona tão bem neste modelo. Se você tem uma empresa menor ou uma com acesso VPN ruim, é aí que realmente brilha.

Uma das razões pelas quais as grandes empresas usam o Perforce pode ser o fato de haver mais profissionais no departamento de TI com muito conhecimento e anos de experiência em solucionar problemas relacionados a ele.

Eu sinto que no futuro as empresas podem começar a se afastar do Perforce e mais para o GIT ... a maioria dos desenvolvedores que conheço parece preferir !! Verifique também http://whygitisbetterthanx.com/#git-is-fast para obter mais evidências sobre por que o Perforce pode não ser tão dominante nos próximos anos!

Algumas vezes, passamos de um conjunto de VCS (sei com certeza que RCS, CVS, ClearCase, Perforce foram usados ​​anteriormente, também pode haver outros) para o Perforce como sistema exclusivo em uso. Esse não foi um projeto pequeno: a migração levou mais de um ano. A equipe (eu não fazia parte dela) responsável avaliou vários VCS, e pelo menos git e svn foram considerados, assim como aqueles que já estavam em uso. Pelo que me lembro do relatório, eles filtraram as ferramentas sem os recursos necessários e depois consideraram:

• desempenho no uso típico, especialmente para sites remotos

• requisitos de recursos

• importância das mudanças necessárias no hábito de trabalhar

• disponibilidade e custo de suporte

e Perforce foi um vencedor bastante claro no geral. O git foi um pouco melhor para o primeiro ponto, mas em desvantagem para os outros.

Era uma vez, não muito tempo atrás (quando o IDE era chamado VI), os únicos sistemas livres (de código aberto) eram CVS, RCS e SCCS.

• Nada disso poderia lidar bem com um arquivo sendo renomeado.
• Eles não registravam mesclagens, portanto, se duas ramificações estavam sendo trabalhadas ativamente, era muito difícil mesclar até que o trabalho terminasse em uma ramificação.
• Eles não foram bem dimensionados para bases de código muito grandes
• Eles não forneceram o nível de controle de acesso e informante do processo que os grandes projetos desejavam.

Havia muitos sistemas comerciais de controle de código-fonte por aí, a maioria deles era fornecida por um único fornecedor de máquina (IBM, DEC, HP, etc) e era executada apenas em seu hardware.

Então, algumas empresas declararam vender controle comercial de código fonte de plataforma cruzada, incluindo Perforce e ClearCase.

O ClearCase foi desenvolvido com base no RPC que não funcionou bem em redes de área ampla (ainda sozinha na Internet) devido ao fato de muitos pacotes de rede pequenos serem ida e volta, também a IBM e a racional consideravam o ClearCase como uma “vaca leiteira” e nunca mostravam muito amar.

Portanto, o único sistema de controle de código-fonte comercial “antigo” que ainda é de uso comum é o Perforce. Quando o perforce está em uso e integrado aos sistemas de construção e aos sistemas de rastreamento de bugs, há muito pouco benefício a curto prazo para uma empresa passar para qualquer outra coisa.

Então, para resumir, forçosamente ficou com o pé na porta quando não havia muitas outras opções, e elas ainda não bagunçaram o suficiente para levar as pessoas a se afastarem .