O que o SVN faz melhor que o Git? [fechadas]

O Subversion é um repositório central

Embora muitas pessoas queiram distribuir repositórios pelos benefícios óbvios de velocidade e múltiplas cópias, há situações em que um repositório central é mais desejável. Por exemplo, se você tem algum pedaço de código que você não quer que ninguém acesse, você provavelmente não quer colocá-lo sob o Git. Muitas corporações querem manter seu código centralizado, e (eu acho) todos os projetos governamentais (sérios) estão sob repositórios centrais.

O Subversion é a sabedoria convencional

Isso quer dizer que muitas pessoas (especialmente gerentes e chefes) têm a maneira usual de numerar as versões e ver o desenvolvimento como uma "linha única" ao longo do tempo codificada em seu cérebro. Sem ofensa, mas a liberalidade de Git não é fácil de engolir. O primeiro capítulo de qualquer livro do Git lhe diz para apagar todos os ideais convencionais de sua mente e começar de novo.

O Subversion faz isso de uma forma e nada mais

O SVN é um sistema de controle de versão. Tem uma forma de fazer o seu trabalho e todos fazem o mesmo. Período. Isso facilita a transição de / para o SVN de / para outro VCS centralizado. O Git NÃO é nem mesmo um VCS puro - é um sistema de arquivos, tem muitas topologias de como configurar repositórios em diferentes situações - e não há nenhum padrão. Isso dificulta a escolha de um.

Outras vantagens são:

• O SVN suporta diretórios vazios
• O SVN tem melhor suporte do Windows
• O SVN pode fazer check-out / clonar uma sub-árvore
• O SVN suporta o controle de acesso exclusivo svn lock , que é útil para arquivos difíceis de serem mesclados
O
• SVN suporta arquivos binários e arquivos grandes com mais facilidade (e não requer a cópia de versões antigas em todos os lugares).
• Adicionar um commit envolve consideravelmente menos etapas, pois não há nenhum pull / push e suas alterações locais são sempre implicitamente substituídas em svn update .

Um benefício do Subversion sobre o Git pode ser que o Subversion permita apenas o check-out de sub-árvores. Com o Git todo o repositório é uma unidade, você pode obter tudo ou nada. Com o código modular, isso pode ser muito bom comparado aos submódulos do Git. (Embora os submódulos do Git também tenham seu lugar, obviamente.)

E um pequeno benefício pequeno: o Subversion pode rastrear diretórios vazios. O Git rastreia o conteúdo do arquivo, portanto, um diretório sem qualquer arquivo não será exibido.

Eu posso pensar em três. Primeiro, é um pouco mais fácil para grok, especialmente para desenvolvedores não. Conceitualmente, é muito mais simples que as opções DCVS . Em segundo lugar está a maturidade, especialmente o TortoiseSVN no Windows. O TortoiseHg está a recuperar rapidamente. Terceiro, a natureza da fera - apenas uma imagem de um sistema de arquivos onde você pode verificar as coisas de qualquer nível da árvore - pode ser bastante útil em alguns cenários - como versionar uma variedade de arquivos de configuração muito diferentes em dezenas de servidores sem dezenas de repositórios.

Isso não quer dizer que não estamos transferindo todo o desenvolvimento para o Mercurial.

• Os repositórios SVN são mais gerenciáveis do ponto de vista de um administrador e administrador ( ACL + métodos de autenticação + hotcopy + espelhos + lixões)
Os
• SVN * -hooks são mais fáceis de implementar e suportam
• svn:external tem mais poder e flexibilidade que submódulos
• Árvores de repositório baseadas em sistema de arquivos são mais fáceis de usar do que repositórios monolíticos com separação somente lógica
• O SVN tem mais diferentes ferramentas do cliente
• O SVN tem front-ends web úteis de terceiros, muito melhores que os do Git
• SVN não quebra seu cérebro

Eu escrevi isso como um comentário sobre a resposta de outra pessoa, mas acho que merece ser uma resposta por si só.

A configuração cuidadosamente escolhida pela minha empresa para o SVN requer o bloqueio no nível do arquivo para editar o conteúdo e nunca usa a mesclagem. Como resultado, vários desenvolvedores disputam bloqueios e podem ser um gargalo principal, e nunca há chance de um conflito de mesclagem.

O SVN definitivamente faz controle gerencial de cima para baixo melhor do que o Git. Na minha migração do skunkworks para o Git (pedindo perdão ao invés de permissão) eu tenho apavorado meu gerente muitas vezes com a noção de que não existe • qualquer servidor de controle principal central com aplicação de software ao qual somos todos escravos.

Minhas razões:

• maturidade - o servidor e as ferramentas (por exemplo, TortoiseSVN)
• simplicidade - menos etapas envolvidas, um commit é um commit. DVCS como Git e Mercurial envolvem commit, depois push.
• tratamento binário - o SVN lida com executáveis binários e imagens melhor que o Git / Hg. Especialmente útil em projetos .NET, pois gosto de verificar as ferramentas relacionadas à criação no controle de origem.
• numeração - o SVN tem um esquema de numeração de confirmação legível, usando apenas dígitos - mais fácil rastrear números de revisão. Git e Hg fazem isso de maneira bem diferente.

Eu aprecio que você esteja procurando por uma boa informação, mas esse tipo de pergunta apenas convida: "Eu acho que Git é muito vitorioso, e svn o suxorz!" respostas.

Eu tentei e pessoalmente achei o Git um pouco demais para o meu pequeno time. Parecia que seria ótimo para uma grande equipe distribuída ou um grupo de equipes geograficamente dispersas. Eu entendo muito os benefícios do Git, mas o controle de fontes, na minha opinião, não é algo que me mantenha acordada à noite.

O ponto que eu estou tentando fazer é que se você é uma pequena equipe trabalhando em um projeto de médio a pequeno e já está familiarizado com o SVN, então use-o. Certamente é melhor que o CVS ou (tremor) SourceSafe , e não preciso de mais de cinco minutos para configurar um repositório. O Git às vezes pode ser um exagero.

Tudo isso é relativo, e, como o maple_shaft disse, se alguém trabalha para você, não mude!

Mas se você realmente quer algo , eu diria que talvez seja melhor para designers, programadores web e tal - ele lida com imagens e arquivos binários um pouco melhor.

Usabilidade. Não é realmente o mérito do Subversion, mas sim o TortoiseSVN 's .. O TortoiseGit existe, mas ainda tem um longo caminho a percorrer para corresponder ao TortoiseSVN.

Se você perguntasse o que o Git faz melhor do que o SVN, eu responderia GitHub . É engraçado como as ferramentas de terceiros fazem uma enorme diferença.

Quando você não precisa se ramificar e mesclar , o SVN (com TortoiseSVN em Windows) é muito fácil de entender e usar. O Git é excessivamente complexo para os casos simples, pois tenta facilitar a integração / ramificação.

(Muitos pequenos projetos nunca precisam se ramificar se forem bem gerenciados. O Git é voltado para casos complexos; portanto, a maioria das documentações do Git pressupõe que você precisa fazer operações complexas, como ramificação e mesclagem.)

Bem, meu avô pode usar o SVN em seu computador com Windows XP, mas ele teria problemas para usar o Git. Talvez isso seja mais uma conquista de TortoiseSVN sobre TortoiseGit , mas eu acho que está bastante ligado ao fato de que o Git é inerentemente mais poderoso e, portanto, mais complexo, e seria inútil deixá-lo no mesmo nível.

Agora, isso realmente não importa para o meu avô, porque ele não fez nenhuma programação ultimamente. No entanto, eu já estive em uma equipe, onde nossos artistas gráficos também usavam nosso controle de origem.

E essas são pessoas que simplesmente esperam que suas ferramentas funcionem (eu também, mas tenho uma chance real de fazê-las funcionar em caso de falha) e sejam intuitivas. Além do fato de que teria sido um grande esforço para levá-los a se dar bem com um DVCS , havia pouco para ser ganho. E com apenas dois programadores na equipe, fazia sentido para nós também ficarmos com o SVN.

No trabalho, não consegui mudar os desenvolvedores do SVN para nenhum DVCS por dois motivos:

• Checkout parcial (como apenas três pastas de diferentes profundidades na árvore do projeto)
• Bloqueio de arquivo (relatórios de formato binário)

• Senso de segurança ao fazer um 'svn commit'. Como os commits vão para o servidor, não há nenhuma falha possível que possa apagar minhas alterações depois que elas forem confirmadas. No git, commits são locais, então até eu empurrar, um stray 'rm -rf' e está tudo acabado.
• As confirmações são autenticadas. Por padrão no git eu posso dizer que estou cometendo como qualquer um.
• Menos comandos para aprender para o uso diário. 'svn checkout', 'svn up' e 'svn commit' levarão você muito longe.
• Os check-outs compartilhados funcionam muito melhor. Quando você vai para commit, ele lhe pede seu nome de usuário / senha, você não precisa se lembrar de passar certos argumentos de linha de comando. Às vezes, no trabalho, temos uma máquina compartilhada com um check-out svn compartilhado de algum projeto. Alguém pode dizer "Bob, você pode ver isso nesta máquina" e ele pode, e ele pode cometer suas mudanças como seu usuário sem nenhum problema.
• Layout do repositório. Você pode ter um projeto de guarda-chuva e subprojetos e escolher o que verificar quando.
• Os números de revisão estão incrementando inteiros.
• Projetado para o fluxo de trabalho do repositório central.

Outras pessoas postaram algumas respostas muito boas, mas e as permissões? Usando o Subversion sobre SSH, você pode criar uma conta separada no seu servidor para o SVN. Diferentes desenvolvedores podem ter acesso diferente a diferentes partes do repositório. O GIT pode fazer isso? Eu acho que há gitolite, mas isso não parece tão flexível ou robusto para mim, nem eu conheço alguém que esteja realmente usando-o.

Velocidade. Às vezes, leva 10 ou 15 minutos para clonar um grande repositório git, enquanto um repositório de subversão de tamanho similar leva alguns minutos para verificar.

Eu postei isso como uma resposta, em vez de um comentário.

Eu admito que o DVCS está bem na moda agora, mas vou tentar dizer por quê.

Os DVCS são melhores porque, como muitas pessoas têm dito, "é assim que deveríamos trabalhar desde o começo". É verdade, você pode fazer com um DVCS o que costumava fazer com o SVN, de modo que o SVN fique obsoleto.

No entanto, nem todo projeto de software é tão bom quanto ele:

• O projeto de longo prazo beneficiou muito do DVCS, porque ele usa menos sobrecarga, permite um gerenciamento muito melhor (ramificação, etc.) e é bastante suportado por hosts como google code e github.

• Esses projetos não são os únicos, existem outros tipos de projetos que estão sendo desenvolvidos em empresas sem qualquer ajuda do mundo externo ou da internet: tudo é feito internamente, e muitas vezes a curto prazo. Um bom exemplo: um videogame. O código evolui rapidamente.

Para o último caso, os desenvolvedores realmente não precisam de recursos de ramificação ou sofisticados que o DVCS pode oferecer, eles só querem compartilhar o código-fonte e os ativos. O código que eles fazem não é susceptível de ser reutilizado, porque existe um prazo. Eles confiam no SVN ao invés de um DVCS por várias razões:

• Os desenvolvedores têm máquinas que pertencem à empresa e isso pode mudar rapidamente. Configurar um repo é uma perda de tempo.
• Se esses caras não tiverem sua própria máquina, eles estarão menos propensos a trabalhar no mesmo código-fonte / parte do projeto. Mais um para os dados centralizados.
• velocidades de rede e muito dinheiro permitem o uso de um servidor centralizado que lida com tudo o SVN, é uma prática ruim, mas backups são feitos, etc.
O
• SVN é apenas mais simples para usar, mesmo que seja o caminho errado: sincronizar arquivos em pares sem redundância não é um problema simples, e "fazer do jeito certo" não pode ser concluído a tempo se você sempre quer que seja perfeito.

Pense na máquina do setor de jogos e em como o SVN economiza tempo; as pessoas se comunicam muito mais nesses projetos porque os jogos são sobre programação repetitiva e código adaptável: não há nada difícil de codificar, mas isso tem que ser feito da maneira certa, o mais rápido possível. Programadores são contratados, eles codificam sua parte, compilam, testam um pouco, cometem, terminam, testadores de jogos lidam com o resto.

DVCS são feitos para a internet e para projetos muito complexos. O SVN é para pequenos projetos de equipe de curto prazo. Você não precisa aprender muito com o SVN, é quase um FTP com um diff idiota.

O Subversion e o Git incentivam abordagens específicas (e muito diferentes) ao desenvolvimento e colaboração. Algumas organizações irão tirar mais proveito do Git, e outras irão tirar mais proveito do Subversion, dependendo de sua organização e cultura.

O Git e o Mercurial são excelentes para equipes distribuídas e pouco organizadas de programadores profissionais altamente competentes. Ambas as ferramentas DVCS populares incentivam pequenos repositórios, com a reutilização entre os desenvolvedores ocorrendo através de bibliotecas publicadas com interfaces (relativamente) estáveis.

O Subversion, por outro lado, incentiva uma estrutura de gerenciamento mais centralizada e strongmente acoplada, com mais comunicação entre os desenvolvedores e um maior grau de controle organizacional sobre as atividades de desenvolvimento do dia-a-dia. Dentro dessas equipes mais compactadas, a reutilização entre os desenvolvedores tende a ocorrer por meio de bibliotecas não publicadas com interfaces (relativamente) instáveis. O TortoiseSVN também permite que o Subversion suporte equipes multidisciplinares com membros que não são programadores profissionais (por exemplo, engenheiros de sistemas, engenheiros de algoritmos ou outros especialistas em áreas temáticas).

Se a sua equipe for distribuída, com membros trabalhando em casa ou em diversos sites internacionais, ou se preferirem trabalhar sozinhos e em silêncio, com pouca comunicação face a face, então um DVCS como o Git ou o Mercurial ser um bom ajuste cultural.

Se, por outro lado, sua equipe estiver localizada em um único site, com uma abordagem de "equipe" ativa para desenvolvimento, e muita comunicação face a face, com um "buzz" no ar, então o SVN pode ser um melhor ajuste cultural, especialmente se você tiver muitas equipes interdisciplinares.

É claro que é possível configurar Git e Hg (poderosos e flexíveis como são) para fazer praticamente o que você quiser, mas é definitivamente mais trabalho, e eles são definitivamente mais difíceis de usar, particularmente para aqueles membros de a equipe que naturalmente não estaria inclinada a usar qualquer forma de controle de versão.

Finalmente, também descubro que a funcionalidade de compartilhamento usando o desenvolvimento de bibliotecas "quentes" sob Svn (com CI e uma abordagem orientada a testes) permite um ritmo de desenvolvimento coordenado que é difícil de alcançar com uma equipe mais distribuída e fracamente acoplada .

Abaixo estão as duas razões pelas quais ainda fico com o SVN.

1. A curva de aprendizado. O SVN é mais fácil que o Git, até mesmo a configuração (servidor ou cliente também), usabilidade e comandos.
2. Melhores pacotes de servidor, como o Edge do Subversion , VisualSVN , uberSVN etc.

Existem duas tendências principais no controle de versão agora; Distribuição e integração .

Git é ótimo em descentralização.

O SVN tem muitas ferramentas construídas que se integram a ele. É comum configurar seu servidor SVN para que, ao fazer o check-in, você mencione o número do bug no comentário de check-in e configure automaticamente isso, mas para um estado "em teste", e alerta o testador atribuído de que precisa olhe para isto. Então você pode marcar uma versão e obter uma lista de todos os bugs corrigidos nesta versão.

As ferramentas que fazem isso com o SVN estão maduras e são usadas todos os dias.

No Subversion, você pode editar as mensagens de log (também chamadas de "commit messages") após o commit ser feito e enviado. Para usos mais práticos, isso é impossível por design em sistemas descentralizados, incluindo o git. Claro, no git você pode fazer "git commit - amend", mas isso não ajuda depois que o seu commit for colocado em outro lugar. No SVN, quando você edita a mensagem de log, você está fazendo isso no repositório central que todos compartilham, assim todos receberão a edição e sem que o identificador da revisão mude.

Editar as mensagens de log após o fato é geralmente muito útil. Além de corrigir um erro ou uma omissão em uma mensagem de log, ele permite fazer coisas como atualizar uma mensagem de log para se referir a uma confirmação futura (como uma revisão que corrige um bug ou conclui o trabalho introduzido na revisão atual).

Não há perigo de perder informações, a propósito. Os ganchos pre-revprop-change e pós-revprop-change podem salvar um histórico das mensagens antigas, se você estiver realmente preocupado, ou enviar e-mails com o diff da mensagem de log (isso é mais comum, na verdade), trilha de auditoria.