Por que grandes empresas usam o Perforce? [fechadas]

113

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?

user34401
fonte
34
Ouvi dizer que o Google usa pastas com o carimbo de data e hora em uma unidade compartilhada! ;)
FrustratedWithFormsDesigner
10
Apenas a unidade compartilhada usa MapReduce, então eles são legais
Paul Stovell
4
Um grande problema será o suporte. Quando você compra o Perforce, está comprando o suporte do desenvolvedor do sistema, algo que você talvez não obtenha do Git.
ChrisF
12
@Anto: Quem se importa com o que Linus diz? Só porque você é um desenvolvedor de kernel brilhante, não significa que você sabe melhor sobre tudo em qualquer lugar.
Billy ONeal
5
Tendo acabado de chegar da Conferência do usuário do Perforce há duas semanas, posso dizer que o Google usa o perforce. Eles recebem mais de 10.000 envios por dia ao seu 1 servidor.
aflat

Respostas:

83

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.

JasonTrue
fonte
3
Obrigado por fornecer uma resposta razoável além da teoria cínica do "jantar e beber". Pode ser verdade para muitas empresas, mas há são algumas razões legítimas que as empresas vão com Perforce (ou reescrevê-lo: P). Não consigo imaginar tentando lidar com a fonte NT no SVN. É verdade que o SVN e o Git estão se atualizando e, talvez, para um novo projeto de grande porte, um deles seja a decisão certa. Mas pense nos custos associados à mudança de um projeto ao vivo tão grande quanto o Windows (todas as versões) de um sistema de controle de origem para outro. Não vale o custo, especialmente quando o sistema de controle de fonte atual funciona.
Greg Jackson
1
Na verdade, eles passaram do SLM (uma ferramenta interna) para o Source Depot (um fork do Perforce), então provavelmente valeu o custo para alguém nesse caso. Mas sim, não vale o custo, a menos que haja um benefício substancial.
JasonTrue
1
discuss.fogcreek.com/joelonsoftware/… tem um pouco dessa história principalmente de fontes externas. (Eu sou um estranho desde 2004, FWIW).
JasonTrue
3
Não tenho certeza da grande situação de repo. Eu administro um, é 12Gb repo (ou seja, o diretório do servidor compactado é 12Gb) e possui 320.000 revisões. É bastante rápido o suficiente. Provavelmente, a Microsoft usou o Perforce porque o SVN não existia em 1999. maillist.perforce.com/pipermail/perforce-user/2001-August/… e subversion.apache.org/docs/release-notes/release-history.html
Gbjbaanb
8
@gbjbaanb, esse não é um repositório grande ... hoje em dia conta como de tamanho médio. ;) Veja, por exemplo, research.google.com/pubs/archive/34459.pdf
Alex Feinman,
65

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.

Bob Murphy
fonte
2
O problema é que grandes empresas colocam seu código em um repositório? Que tal colocar cada 'módulo' ou 'aplicativo' em um repositório Git separado, para que os tamanhos desses repositórios sejam gerenciáveis? Cada um desses repositórios importaria as funcionalidades necessárias usando o recurso do submódulo do Git. Dessa maneira, os mantenedores dos repositórios ocasionalmente pullusavam seus submódulos para obter atualizações ou novos recursos, e somente então os usuários desse repositório precisavam de atualizações maiores que o código do próprio repositório.
Carl G
@Carl G: Se você ler todas as respostas aqui, encontrará várias razões pelas quais as pessoas escolheram o Perforce em vez do git que nada têm a ver com os recursos do git em repositórios ou submódulos.
9788 Bob Marphy
Eu estava tentando abordar "o tempo que leva para preencher inicialmente uma árvore de origem", mas, na verdade, posso ver que o problema do sub-módulo que mencionei é irrelevante porque os sub-módulos também contêm todos os históricos desses repositórios. Eu acho que a única maneira de reduzir a história seria usar binários das dependências.
Carl G
Bem, com o git, você pode fazer um clone superficial e obter apenas uma pequena quantidade de histórico, ou talvez apenas os arquivos mais recentes (git clone - profundidade 1). Isso funciona também para os submódulos do git.
Sahil Singh
38

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.

Wyatt Barnett
fonte
4
+1. Mudamos para o git há relativamente pouco tempo, e tivemos que correr forçosamente por muito tempo - apenas porque todo o resto era inferior.
9000
11
Embora o IMO Perforce desperdice muito do meu tempo. Ainda o usamos no trabalho porque investimos tempo no desenvolvimento de ferramentas personalizadas que interagem com ele. Para mudar, teríamos que reconstruir essas ferramentas.
M4tt1mus
2
Desenvolvedores forçados e ignorantes me fizeram odiar o check-in de código. Prefiro escrever código com giz de cera e compilar isso .
Jim Schubert
Eu acho que você deve dar uma olhada no forforce antes de comentar.
Toby Allen
30

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.
Mike O'Connor
fonte
19
Eu acho que os desenvolvedores "antigos" (+10 anos) provavelmente são tão resistentes à mudança quanto as pessoas "não técnicas".
Wayne Werner
3
+1 sobre isso, especificamente para esse setor. Os programadores de videogame tendem a ter tanto em jogo, que mudar a infraestrutura com a qual trabalham é uma proposta assustadora. "Se não está quebrado ..." é um mantra e muitas vezes impede a indústria de seguir em frente com soluções mais antigas, mesmo que sejam mais adequadas.
22611 Chris Subagio
2
@ Wayne - comentário totalmente etista. Tenho mais de sessenta anos e sou o principal defensor da mudança e da inovação em meu site de médio porte. James Gosling tinha 46 anos quando começou a escrever a primeira JVM. Ken Thomson tinha 49 anos quando criou o esquema de codificação UTF-8 e 63 quando começou a trabalhar no idioma GO.
James Anderson
1
@ JamesAnderson Eu acho que você provavelmente está lá. E se sua organização não tem uma cultura de aprimoramento, você verá o efeito do Mar Morto . Gostaria de saber se é possível alterar o sistema como um todo, ou se podemos apenas mexer com nossa pequena parte dele.
Wayne Werner
2
@ MikeO'Connor Você também esqueceu de colocar que os jogos usam muitos ativos binários. Ser capaz de bloquear exclusivamente ativos binários é uma enorme vantagem.
CodingMadeEasy 3/16/16
22

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.

David W.
fonte
40
Espere o que? Você me perdeu aqui "A fusão do Forforce é melhor que o Subversion ou o Git. O Git realmente não faz mesclagens [...]". Você pode explicar isso?
Sverre Rabbelier
1
Na verdade, acho o Git muito bom para mesclagens, mais agradável do que as ferramentas scm da velha escola, mas quando em svn sinto falta de colocar coisas em uma lista de alterações "não faça check-in", como costumava fazer com o Perforce. (Eu tentei fazê-lo no SVN, mas ainda assim verifico acidentalmente as coisas porque as listas de alterações svn e p4 se comportam de maneira diferente).
JasonTrue
12
@SverreRabbelier 3 anos depois, e ainda há pessoas esperando uma resposta para sua pergunta.
Navin
1
"porque Perforce é melhor" ... "Este não é um jogo de futebol em que um time é melhor que outro". ...
RJFalconer
4
forçosamente é rápido. muito mais rápido que svn ou git. --- benchmarks, ou isso não aconteceu ...; p
sjas
14

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.

gbjbaanb
fonte
Esse foi um argumento mais convincente há uma década, mas muitos produtos de software livre são muito populares hoje em dia; incluindo o SVN, usado em algumas grandes empresas.
Jeremy
Não ligo para que a FOSS tenha as coisas certas para competir - ligo para que meu gerente pense que não. Além disso, algumas grandes empresas se movem devagar para que ainda cheguem lá, e levará algumas delas mais alguns anos para avaliar os produtos FOSS.
Gbjbaanb
gbjbaanb Você me entendeu mal. Eu não acho que os fatores que você está descrevendo sejam tão relevantes em qualquer nível de gerenciamento quanto eram há uma década atrás. Embora essa seja sua situação, seria errado generalizá-la. O FOSS é popular, o que significa que é adotado pela maioria das grandes empresas e usado em sistemas principais.
21411 Jeremy
6
Penso que este é um ponto-chave: as ferramentas de software livre não se anunciam, realmente porque não têm motivos para isso. Parte disso são os folhetos e outras coisas que você menciona, mas mesmo que eu pesquise no Google "sistemas SCM de comparação" ou "sistema de controle de versão de comparação", as únicas coisas que encontro são as feitas pelo Perforce. Claro, eu tenho que considerar a fonte, mas não conheço as ferramentas de software livre que se esforçam para anunciar a si mesmas e falar sobre por que elas são as melhores. Sei que desprezamos o comercialismo, mas às vezes o marketing e a publicidade realmente me ajudam a fazer uma escolha informada.
Chance
1
Acho que existem duas excelentes razões para não escolher o Perforce: 1. A ramificação é muito cara e 2. O processo de checkout e edição torna o trabalho offline muito difícil de conciliar.
precisa saber é o seguinte
14

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.

Dmitri
fonte
13
Pode parecer cínico, mas essencialmente você acertou a unha na cabeça. Na minha própria empresa, luto para promover qualquer solução de software livre, pois o executivo tem a percepção de que, se for gratuito, não pode ser bom.
wolfgangsz
1
por isso, embora eu possa tê-los convertido um pouco quando substituíram nossa solução SVN por uma 'empresa' que custou uma fortuna, exigiu consultores, 2 contratados para administrá-la e, depois de muita lamentação, ranger de dentes e operação de buggy e a morte de nossa produtividade ... foi descartada e substituída pela nossa antiga solução SVN.
Gbjbaanb
7
O Google não é realmente conhecido por esse tipo de cultura.
21411 Jeremy
11
@ Chance: Para que tipo de coisas você entra em contato com o suporte técnico? Eu usei CVS, Subversion e Mercurial, e nunca me vi desejando que houvesse alguém para quem eu pudesse ligar. Se eu tiver um problema, pesquiso no Google ou coloco uma pergunta, e ela é resolvida, geralmente em alguns minutos. Eu sugiro que uma ferramenta de controle de origem que exija suporte do desenvolvedor do sistema tenha um problema sério.
Tom Anderson
2
@TobyAllen: não por cerca de seis anos (observe a data de questão), mas estes dias, parece que até mesmo Perforce quer usar algo diferente do Perforce: perforce.com/git
Dmitri
12

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.

Michael
fonte
2
Eu concordo: esse é um grande motivo para muitos departamentos de TI, mas parece imaturo. "Não é nossa culpa, é SUA FALHA". Escolher um produto inferior apenas por causa do potencial de apontar o dedo "um pescoço para torcer" parece uma decisão infantil. Não que isso não seja feito com frequência, apenas que parece infantil.
precisa
Sua resposta não se refere ao suporte técnico da Perforce. Que pena, porque se você soubesse o quão boa era, sua resposta pode não ter surgido. O suporte técnico da Forforce é estelar e comprometido, e eles consertam as coisas RAPIDAMENTE.
Br.Bill
9

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

manojlds
fonte
1
Absolutamente, subrepos incentivam e facilitam a reutilização de código. É por isso que escolhi o Perforce quando tenho uma opinião sobre o assunto. Grande negócio! Misture e combine facilmente códigos de diferentes repositórios (subrepos da hg), rastreando quem está usando um subrepo específico, capacidade de rastrear facilmente check-ins, ramificações e mesclagens em todos os repositórios. Enquanto isso, torna-se super simples para o desenvolvedor final com uma especificação de cliente de linha única e mantém os detalhes na especificação de ramificação para os superusuários. No momento, sou forçado a usar o Mercurial em um grande projeto, e lidar com substituições com hg está custando MUITO dinheiro em perda de produtividade.
22412 stephenmm
8

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.

Martin Ba
fonte
5
Você pode usar o Git perfeitamente com diferentes fluxos de trabalho, portanto, distribuir não é um problema ... a menos que a equipe da empresa não tenha noção. Por que razão gitisbetterthanx.com/#any-workflow
M. Dudley
2
Eu não diria que o Perforce se ramifica bem ... criar ramificações do Perforce resulta em uma cópia ocupada de tudo que é ramificado. O SVN ramifica por cópia lenta, portanto, ramifica muito mais rapidamente.
precisa saber é o seguinte
1
@ Jason - ramificação no subversion acontece mais rápido do que eu posso digitar: "svn cp ...; svn switch ..." No forforce, a criação de ramificações é incrivelmente complexa; crie uma especificação de ramificação, crie um espaço de trabalho, integre, confirme. Caramba, com força é tudo assim. Sem ramificação rápida e fácil, considero que um RCS é essencialmente inutilizável. A julgar pelo tráfego líquido e pela velocidade do aprimoramento, parece que o Perforce é um produto em fim de vida.
precisa
1
@ Kevin, eu não tenho certeza de como você está ramificando, mas eu apenas integro e comprometo parte. Eu nunca fiz a especificação da ramificação e nunca precisei criar uma área de trabalho para ramificar (embora eu possa ter tido que alterar meu mapeamento de exibição se decidi excluir diretórios na minha exibição). Dito isto, não fiz nada com o svn, portanto não posso comentar sobre esse aspecto.
Chance
1
@ Kevin: Você sabia, se algo "funciona melhor" não é necessariamente uma função do número de comandos da CLI necessários para fazê-lo. Apenas um comentário de alguém que não é muito proficiente nem no SVN nem no Perforce.
Martin Ba
6

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.

Bruce Ediger
fonte
sem comentários, mas quero saber qual de nossos contratados ou gerentes jogou biquíni!
Gbjbaanb
5
Eu admito, o Bikini Golf provavelmente também funcionaria comigo.
precisa saber é o seguinte
5

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.

um apartamento
fonte
2
É tudo sobre definir o fluxo de trabalho, centralizado ou descentralizado, não importa. O trabalho do suporte não é mais fácil ao tentar percorrer 200 filiais no repositório central. De um modo geral, as empresas escolhem soluções centralizadas porque é com isso que se sentem confortáveis. Não há vantagens consideráveis ​​sobre um DVCS usado com um repositório compartilhado centralizado.
23411 wadesworld
4

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!

rrazd
fonte
4

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.

AProgrammer
fonte
3

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 .

Ian
fonte