Eu procurei e não conseguimos encontrar negócios razões por que git / mercurial / bazzr sistemas são melhores do que sistemas centralizados (subversão, forçosamente).

Se você estava tentando vender um DVCS para uma pessoa não técnica, quais argumentos você forneceria para o aumento do lucro do DVCS .

Em breve, lançarei o git para o meu gerente, levará algum tempo convertendo os repositórios do subversion e algumas despesas na compra de licenças de smartgit.

Editar Tentei transformar essa pergunta em uma discussão genérica sobre centralizado versus descentralizado, mas inevitavelmente ele se transformou em git vs subversão. Certamente existem melhores sistemas centralizados que o subversion.

Hmm, como gerente, tenho duas reações imediatas a esse ponto:

• Se você ainda não tem boas razões, por que está lançando um git diferente de estar na moda?
• Da mesma forma, como o Subversion está falhando e você precisa de uma substituição?

Na verdade, não sou negativo - acho que provavelmente existe um caso a ser feito (dependendo das circunstâncias), mas se o caso for simplesmente que o git é "melhor" do que a subversão, então você realmente não tem um.

Você também precisa ser capaz de enumerar as desvantagens - você já identificou a sobrecarga da migração e da reformulação de ferramentas - o que mais é um problema? Por exemplo, o que acontece com seu repositório legal, central e com backup? Como você se integra ao seu servidor de construção de integração contínua (se você não possui um, esqueça o git e classifique-o primeiro). Segurança e rastreamento - o SVN é executado com logins e permissões adequados.

Na minha opinião, os benefícios estão na flexibilidade, na melhor fusão, na capacidade de realizar confirmações locais sem interromper a construção e assim por diante. As desvantagens estão na falta de controle e na mesma flexibilidade.

Pode ser que tudo o que você queira fazer seja executar o git localmente em sua máquina como um cliente "melhor" do subversion (eu estou olhando para fazer isso usando mercurial).

Hmm, talvez toda essa resposta seja realmente um comentário? Você precisa defender aqui (na pergunta) o git over subversion (em seu ambiente) para ver se podemos ajudá-lo a identificar o caso de negócios.

FWIW, eu sei que é possível designar facilmente uma instância específica do repositório para ser a fonte de tronco / referência e, além disso, é assim que se liga ao servidor de construção - a diferença é que, com o DVCS, é mais uma decisão administrativa do que algo inerente à arquitetura.

Eu diria que a ramificação e mesclagem rápidas e indolentes permitiriam que os desenvolvedores fossem mais produtivos com seu código, já que todos os novos recursos poderiam ser ramificados e posteriormente mesclados. Tornando o processo de desenvolvimento muito mais tranquilo. Além disso, a natureza distribuída permitiria que todos os desenvolvedores tivessem uma cópia inteira do código; portanto, não há nenhuma preocupação de uma falha centralizada do servidor derrubar todo o seu código. Provavelmente existem mais razões, essas duas, no entanto, são minhas principais razões para usar o Git.

Presumo que você possa defender o controle de versão, aumentando a produtividade (e, portanto, o lucro), mesmo quando um desenvolvedor estiver trabalhando sozinho.

Um bom DVCS reconhece os mesmos benefícios de produtividade, mesmo quando trabalha em equipe - cada desenvolvedor pode obter todos os benefícios de trabalhar com controle de versão - pode fazer confirmações frequentes, retrocessos, brincar com as coisas etc. - sem se preocupar com conflitos com o que os outros desenvolvedores estão fazendo até estarem prontos para fazer as alterações.

• Ramificação por bug
• Latência reduzida em suas diferenças.
• Ser capaz de navegar muito rapidamente arbitrariamente pelo histórico de uma filial quando você estiver revisando por pares.
• Você ainda tem acesso a todo o seu histórico quando não tem acesso ao servidor centralizado: você não está no escritório, a energia acabou, mas a bateria do laptop ainda está funcionando, ...

Essas coisas permitem que você trabalhe com mais eficiência, sozinho ou em equipe. Trabalho mais eficiente = menor tempo de desenvolvimento = menor tempo de colocação no mercado = lucro.

Perdoe-me por criar um link para meu próprio blog, mas escrevi artigos sobre esse assunto:

• Por que a dica deve sempre compilar
• Por que o DVCS fornece melhor controle central
• Por que a ramificação é melhor com o DVCS
• Por que os modelos de ramificação distribuída podem não funcionar bem no seu CVCS .

Sinta-se livre para votar se você não os achar relevantes.

Em poucas palavras, o DVCS facilita os modelos de ramificação que podem impedir que grandes grupos de desenvolvedores pisem nos dedos uns dos outros, o que aumenta a produtividade e a qualidade da sua construção diária. A parte confusa da colaboração do controle de versão pode ser feita em repositórios locais, deixando o repositório central mais limpo e de maior qualidade. Além disso, as decisões sobre quando ramificar podem ter um grande efeito na eficiência, por exemplo, se um departamento está pronto para começar a trabalhar no 2.0 quando o 1.0 ainda está sendo limpo por outros. O DVCS permite que essas decisões sejam tomadas em nível local e não por comitê.

Meus argumentos para DVCS são estes:

• A ramificação não é interrompida, o que leva a menos atritos no desenvolvimento de recursos e na manutenção dos produtos existentes. O atrito custa dinheiro a tempo.

• A mudança para um sistema moderno atrai melhor desenvolvedores de ponta, o que levará a uma cultura de melhores produtos, o que permitirá que a empresa venda mais produtos.

• As confirmações que não são de rede são mais rápidas , permitindo que os desenvolvedores se comprometam com frequência, levando à detecção e análise de erros refinados.

Essencialmente, trata-se de reduzir o atrito. Existe um termo para isso: Muda . Quanto mais atrito, mais dor é fazer as coisas. Quanto mais dor, menos trabalho, menos lucros.

Peço desculpas se estou me destacando, mas permita-me colocar o caso comercial em termos inequívocos:

O SVN torna a vida dos desenvolvedores miserável . E isso torna um negócio de software miserável.

... de maneiras que muitos não perceberão até começarem a usar um DVCS. Esse é o caso de negócios mais importante que pode ser feito . Por quê? Bem, comparado ao custo de encontrar e reter bons desenvolvedores, o custo de mudar para um DVCS é quase inexistente .

Considere o seguinte:

• Todas, exceto as operações mais triviais no SVN (e na maioria dos outros CVCSes), exigem acesso à rede. Na maioria dos DVCSes, acesso à rede só ocorre quando você faz uma pushou pulloperação. Isso significa que comandos não triviais são lentos . O que você faz quando um comando leva uma eternidade? Pessoalmente, vou procurar notícias de programadores ou hackers enquanto espero. Simplificando, os DVCSes permitem que os programadores se concentrem em fazer o que amam: escrever o software da empresa .
• O SVN tem suporte para ramificação da mesma maneira que as prisões têm suporte para deixar seu sabão cair no chuveiro: você pode fazê-lo, mas quando você fica fodido. Assim, o SVN força seus desenvolvedores a brigar constantemente entre si para fazer alterações .
• Quando o SVN está inoperante, está inoperante. Torna-se terrivelmente difícil para os desenvolvedores fazerem seu trabalho, se é que podem fazê-lo. Assim, o SVN força seus desenvolvedores a confiarem em sua infraestrutura, sendo 100% livre de erros .
• Hoje em dia, o git está rapidamente ganhando atenção, enquanto o SVN está perdendo rapidamente. Se não há benefícios em usar DVCSes sobre SVN, por que a comunidade de programação está mudando o mais rápido possível?

O que isso significa? Ainda não encontrei um desenvolvedor que tenha feito uma tentativa honesta ao DVCS que preferiria o SVN posteriormente. Se eu pudesse fazer mais uma afirmação irritante e ousada, o SVN é um "mal necessário" que os desenvolvedores se forçam a usar. Git é uma ferramenta que torna os desenvolvedores mais produtivos e felizes .

(Devo salientar que as declarações em negrito são aquelas em que você deve se concentrar. O restante apenas fornece contexto.)

A única coisa que consigo pensar é que o git funciona sem uma conexão de rede. Todo o resto é até difícil de vender para usuários técnicos que usam submersão ou força por algum tempo.

A diferença mostra quando há problemas

Mudamos para o git há 6 meses depois de portar nosso repositório de uma década.

Até agora, encontrei o seguinte, depois de algumas experiências:

• ramificação e fusão é quase indolor. Isso facilita muito o trabalho em recursos separados e correção de erros sem pisar nos dedos um do outro. Também torna muito fácil aplicar uma determinada correção de bug em outro lugar também.

• mais robusto por design - você não confia 100% na disponibilidade de um servidor central; caso contrário, pode promover temporariamente qualquer clone como substituto a quente. Isso remove um ponto crucial de falha - se o servidor SVN ficar inativo por qualquer motivo, ninguém poderá fazer o trabalho do SVN. Se o repositório central do git for desativado por qualquer motivo, você ainda poderá trabalhar e pressionar / puxar localmente para garantir que as confirmações sejam replicadas. Você pode até ter vários repositórios externos exatamente para esse fim.

• a interação do repositório é simplificada. Para o CVS, você basicamente precisava acessar o tempo todo, sempre que precisava de alguma informação. Para o git, todo o repositório está disponível localmente, permitindo que muitas coisas aconteçam mais rapidamente.

Portanto, o benefício não é tanto na rotina diária, mas é muito claro no momento em que você tem algo que não está funcionando corretamente!

Portanto, sugiro que, no seu caso de negócios, observe o que você fará quando ocorrer um desastre ...

A facilidade de ramificar e mesclar é a razão mais concreta, mas para convencer alguém, você precisará dar um exemplo concreto de como isso melhora as coisas.

Digamos que você tenha alguns programadores trabalhando em melhorias de desempenho para um aplicativo, e eles estão no estágio experimental e não sabem se o código que estão escrevendo fará parte do ramo mestre / tronco. No entanto, eles precisam compartilhar código frequentemente e experimentar idéias que podem ser becos sem saída. Como você gerencia ramificações e mesclagens tão freqüentes no subversion? A resposta curta é que você não. Com um dvcs, é realmente fácil, e os programadores podem experimentar rapidamente novas idéias em ramificações e compartilhar com outras pessoas antes de decidir se essa ideia será mantida.

O argumento comercial para abandonar o SubVersion é o suporte à ramificação, que é uma barreira para a estabilização e manutenção do produto. Se você precisar liberar um produto e continuar o desenvolvimento, precisará de uma ramificação. Com o subversion, os desenvolvedores não usarão a ramificação corretamente, e assim você falhará em manter o desenvolvimento no tunk e garantir que as correções de bugs também o façam no tronco e no branch.