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

Não há dúvida de que a maioria dos debates sobre as ferramentas do programador destila a escolha pessoal (pelo usuário) ou a ênfase no design , ou seja , otimizar o design de acordo com casos de uso específicos (pelo criador da ferramenta). Os editores de texto são provavelmente o exemplo mais proeminente - um codificador que trabalha no Windows no trabalho e codifica em Haskell no Mac em casa, valoriza a integração entre plataformas e compiladores e escolhe o Emacs em vez do TextMate etc.

É menos comum que uma tecnologia recém-introduzida seja genuinamente, comprovadamente superior às opções existentes.

Este é de fato o caso dos sistemas de controle de versão (VCS), em particular, VCS centralizado ( CVS e SVN ) versus VCS distribuído ( Git e Mercurial )?

Eu usei o SVN por cerca de cinco anos, e atualmente o SVN é usado onde trabalho. Há pouco menos de três anos, mudei para o Git (e GitHub) para todos os meus projetos pessoais.

Eu posso pensar em várias vantagens do Git sobre o Subversion (e que na maioria das vezes abstraem das vantagens do VCS centralizado), mas não consigo pensar em um contra-exemplo - alguma tarefa (que é relevante e surge nos programas habituais dos programadores) workflow) que o Subversion se sai melhor que o Git.

A única conclusão que tirei disso é que não tenho dados - não que o Git seja melhor etc.

Meu palpite é que tais contra-exemplos existem, daí esta questão.

Subversion é um repositório central

Embora muitas pessoas desejem ter repositórios distribuídos para os benefícios óbvios da velocidade e várias cópias, há situações em que um repositório central é mais desejável. Por exemplo, se você tem algum código crítico que não deseja que ninguém acesse, provavelmente não deseja colocá-lo no Git. Muitas empresas querem manter seu código centralizado e (eu acho) todos os projetos governamentais (sérios) estão sob repositórios centrais.

Subversão é sabedoria convencional

Isso significa 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 codificado em seus cérebros. Sem ofensa, mas a liberalidade de Git não é fácil de engolir. O primeiro capítulo de qualquer livro do Git diz para você deixar em branco todos os ideais convencionais e começar de novo.

O Subversion faz isso de uma maneira, e nada mais

SVN é um sistema de controle de versão. Ele tem uma maneira de fazer seu trabalho e todo mundo faz da mesma maneira. Período. Isso facilita a transição de / para SVN de / para outros VCS centralizados. O Git NÃO é nem um VCS puro - é um sistema de arquivos, possui muitas topologias para configurar repositórios em diferentes situações - e não há nenhum padrão. Isso dificulta a escolha de um.

Outras vantagens são:

• SVN suporta diretórios vazios
• SVN tem melhor suporte do Windows
• O SVN pode fazer check-out / clonar uma subárvore
• O SVN suporta controle de acesso exclusivo, svn lockútil para arquivos difíceis de mesclar
• 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).
• A adição de uma confirmação envolve consideravelmente menos etapas, já que não há pull / push e suas alterações locais são sempre implicitamente rebaseadas svn update.

Um benefício do Subversion sobre o Git pode ser que o Subversion permite verificar apenas as subárvores. Com o Git, todo o repositório é uma unidade, você pode obter apenas tudo ou nada. Com o código modular, isso pode ser bastante bom se comparado aos sub-módulos Git. (Enquanto os submódulos do Git também têm seu lugar, obviamente.)

E um pequeno benefício: o Subversion pode rastrear diretórios vazios. O Git rastreia o conteúdo do arquivo, para que um diretório sem nenhum arquivo seja exibido.

Eu consigo pensar em três. Primeiro, é um pouco mais fácil grok, especialmente para não desenvolvedores. Conceitualmente, é muito mais simples que as opções do DCVS . O segundo é a maturidade, especialmente o TortoiseSVN no Windows. TortoiseHg está alcançando rápido embora. Terceiro, a natureza da fera - apenas uma imagem de um sistema de arquivos onde você pode verificar coisas de qualquer nível da árvore - pode ser bastante útil em alguns cenários - como criar uma variedade de arquivos de configuração amplamente diferentes em dezenas de 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 gerente e administrador ( ACL + métodos de autenticação + hotcopy + espelhos + dumps)
• Os ganchos SVN * são mais fáceis de implementar e suportar
• svn:external tem mais poder e flexibilidade do que os submódulos
• As árvores de repositório baseadas no sistema de arquivos são mais fáceis de usar do que os repositórios monolíticos com separação somente lógica
• O SVN tem mais ferramentas-cliente diferentes
• O SVN possui front-end utilizáveis ​​por terceiros, muito melhores que os do Git
• SVN não quebra seu cérebro

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 da minha empresa para o SVN requer bloqueio no nível do arquivo para editar o conteúdo e nunca usa mesclagem. Como resultado, vários desenvolvedores disputam bloqueios, e pode ser um grande gargalo, e nunca há chance de um conflito de mesclagem.

O SVN definitivamente faz o controle gerencial de cima para baixo melhor que o Git. Na migração do skunkworks para o Git (pedindo perdão, em vez de permissão), eu aterrorizei meu gerente muitas vezes com a noção de que não há nenhum servidor de controle mestre central imposto por software no qual todos somos 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 e, em seguida, empurram.
• manipulação binária - o SVN lida com executáveis ​​e imagens binários melhor que o Git / Hg. Especialmente útil em projetos .NET, pois gosto de verificar ferramentas relacionadas à compilação no controle de origem.
• numeração - o SVN possui um esquema de numeração de confirmação legível, usando apenas dígitos - mais fácil de rastrear os números de revisão. Git e Hg fazem isso de maneira bem diferente.

Compreendo que você esteja procurando por boas informações, mas esse tipo de pergunta apenas convida: "Eu acho que o Git é muita vitória e muito obrigado!" respostas.

Tentei e pessoalmente achei o Git um pouco demais para minha pequena equipe. Parecia que seria ótimo para uma grande equipe distribuída ou um grupo de equipes geograficamente dispersas. Entendo muito os benefícios do Git, mas, na minha opinião, o controle da fonte não é algo que me mantém acordado à noite.

Eu sou um caçador de veados, e quando eu e meus amigos saímos eles estão armados até os dentes, cheios de munição e equipamentos de alta tecnologia. Eu apareço com um único rifle, sete balas e uma faca. Se eu precisar de mais de sete rodadas, estou fazendo algo errado, e preciso tanto quanto qualquer outra pessoa.

O que estou tentando enfatizar é que, se você é uma equipe pequena trabalhando em um projeto de médio a pequeno porte e já conhece o SVN, use-o. Certamente é melhor que o CVS ou o SourceSafe (estremecedor) , e não levo mais de cinco minutos para configurar um repositório. Às vezes, o Git pode ser um exagero.

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

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

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

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

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

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

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

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

E são pessoas que simplesmente esperam que suas ferramentas funcionem (eu também, mas tenho uma chance realista de fazê-las funcionar em caso de falha) e são intuitivas. Além do fato de que teria sido um grande esforço conseguir que eles se dessem bem com um DVCS , havia pouco a ganhar. E com apenas dois programadores na equipe, fazia sentido também ficarmos com o SVN.

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

• Verificações parciais (como apenas três pastas de diferentes profundidades na árvore do projeto)
• Bloqueio de arquivo (relatórios de formato binário)

• Sensação de segurança ao executar um 'svn commit'. Como as confirmações vão para o servidor, não há nenhuma possibilidade de que eu possa fazer que apague minhas alterações depois que elas forem confirmadas. No git, os commit são locais, então até eu pressionar, um 'rm -rf' perdido e tudo acaba.
• As confirmações são autenticadas. Por padrão no git, posso dizer que estou comprometendo como qualquer um.
• Menos comandos para aprender no uso diário. 'svn checkout', 'svn up' e 'svn commit' levarão você muito longe.
• As caixas compartilhadas funcionam muito melhor. Quando você vai confirmar, ele solicita seu nome de usuário / senha, e você não precisa se lembrar de passar certos argumentos da linha de comando. Às vezes, no trabalho, temos uma máquina compartilhada com um svn checkout compartilhado de algum projeto. Alguém pode dizer "Bob, você pode ver isso nesta máquina" e ele pode, e ele pode confirmar suas alterações como seu usuário, sem qualquer problema.
• Layout do repositório. Você pode ter um projeto abrangente e subprojetos e escolher o que verificar quando.
• Os números de revisão estão incrementando números inteiros.
• Projetado para o fluxo de trabalho do repositório central.

Outras pessoas postaram respostas muito boas, mas e as Permissões? Usando o Subversion over SSH, você pode criar uma conta separada no servidor para o SVN. Diferentes desenvolvedores podem ter acesso diferente a diferentes partes do repositório. O GIT pode fazer isso? Eu acho que existe gitolita, mas simplesmente não me parece tão flexível ou robusto, nem conheço ninguém que esteja realmente usando.

Rapidez. Às vezes, leva 10 ou 15 minutos para clonar um grande repositório git, enquanto um repositório de subversão de tamanho semelhante leva alguns minutos para fazer o check-out.

Coloco isso como uma resposta e não como um comentário.

Eu admito que o DVCS está bastante na moda agora, mas vou tentar explicar o porquê.

Os DVCS são melhores porque, como muitas pessoas dizem, "é assim que deveríamos estar trabalhando desde o início". É verdade, você pode fazer com um DVCS o que costumava fazer com o SVN, de maneira que torne o SVN obsoleto.

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

• Os projetos de longo prazo se beneficiaram muito do DVCS, porque utiliza menos sobrecarga, permite um gerenciamento muito melhor (ramificação etc.) e é muito suportado por hosts como o código do google e o github.

• Esses projetos não são os únicos, existem outros tipos de projetos que estão sendo desenvolvidos em empresas sem nenhuma assistência do mundo exterior ou da Internet: tudo é feito internamente e, geralmente, a curto prazo. Um bom exemplo: um videogame. O código evolui rapidamente.

No último caso, os desenvolvedores não precisam realmente de recursos sofisticados ou ramificados que o DVCS possa oferecer, apenas desejam compartilhar código-fonte e ativos. O código que eles criam provavelmente não será reutilizado, porque há um prazo. Eles confiam no SVN em vez de no DVCS por vários motivos:

• Os desenvolvedores têm máquinas que pertencem à empresa, e isso pode mudar rapidamente. Configurar um repositório é uma perda de tempo.
• Se esses caras não tiverem sua própria máquina, é menos provável que estejam trabalhando 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 que é SVN, é uma prática ruim, mas são feitos backups etc.
• O SVN é mais simples de usar, mesmo se for da maneira errada: sincronizar arquivos em pares sem redundância não é um problema simples, e "faça da maneira certa" não poderá chegar a tempo se você sempre quiser que seja perfeito.

Pense na máquina da indústria 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 adaptativo: não há nada difícil de codificar, mas isso deve ser feito da maneira certa, o mais rápido possível. Os programadores são contratados, eles codificam sua parte, compilam, testam um pouco, comprometem, concluem, os testadores de jogos lidam com o resto.

DVCS são feitos para a internet e para projetos muito complexos. SVN são para projetos de equipe pequenos, de curto prazo e restritos. Você não precisa aprender muito com o SVN, é quase um FTP com uma diferença estúpida.

O Subversion e o Git encorajam abordagens particulares (e muito diferentes) ao desenvolvimento e colaboração. Algumas organizações tiram mais proveito do Git, e outras tiram mais proveito do Subversion, dependendo de sua organização e cultura.

Git e Mercurial são excelentes para equipes distribuídas e pouco organizadas de programadores profissionais altamente competentes. Essas duas ferramentas populares do DVCS incentivam pequenos repositórios, com a reutilização entre 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 fortemente acoplada, com mais comunicação entre os desenvolvedores e um maior grau de controle organizacional sobre as atividades diárias de desenvolvimento. Dentro dessas equipes mais compactamente organizadas, a reutilização entre desenvolvedores tende a ocorrer através de bibliotecas não publicadas com interfaces (relativamente) instáveis. O TortoiseSVN também permite ao Subversion dar suporte a equipes multidisciplinares com membros que não são programadores profissionais (por exemplo, engenheiros de sistemas, engenheiros de algoritmos ou outros especialistas na área).

Se sua equipe estiver distribuída, com membros trabalhando em casa ou em muitos sites internacionais diferentes, ou se preferirem trabalhar sozinhos e em silêncio, com pouca comunicação face a face, um DVCS como Git ou Mercurial será uma boa opção. ajuste cultural.

Se, por outro lado, sua equipe estiver localizada em um único site, com uma abordagem ativa de "equipe" para o desenvolvimento e muita comunicação presencial, com um "burburinho" no ar, o SVN poderá ser um melhor ajuste cultural, principalmente se você tiver muitas equipes interdisciplinares.

Obviamente, é possível configurar o Git e o Hg (por mais poderosos e flexíveis que sejam) para fazer praticamente o que você quiser, mas é definitivamente mais trabalho, e eles são definitivamente mais difíceis de usar, principalmente para os membros da equipe que naturalmente não estaria inclinado a usar qualquer forma de controle de versão.

Por fim, também acho que o compartilhamento de funcionalidades usando o desenvolvimento de bibliotecas "quentes" no 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 com pouco acoplamento.

Abaixo estão as duas razões pelas quais ainda permaneço no SVN.

1. A curva de aprendizado. O SVN é mais fácil que o Git, mesmo a configuração (servidor ou cliente também), usabilidade e comandos.
2. Pacotes de servidor melhores, como Subversion Edge , 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 criadas que se integram a ele. É comum configurar o servidor SVN para que, quando você fizer o check-in de uma correção, mencione o número do bug no comentário do check-in e o defina automaticamente, exceto para o estado "em teste", e avise o testador designado de que eles precisam olhe para isso. Em seguida, 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 são maduras e usadas todos os dias.

No Subversion, você pode editar mensagens de log (também chamadas de "mensagens de confirmação") depois que a confirmação for concluída e enviada por push. Para usos mais práticos, isso é impossível por design em sistemas descentralizados, incluindo o git. Obviamente, no git, você pode executar o "git commit --amend", mas isso não ajuda após o envio do commit para outro lugar. No SVN, quando você edita a mensagem de log, está fazendo isso no repositório central que todos compartilham, para que todos obtenham a edição e sem que o identificador da revisão seja alterado.

A edição de mensagens de log após o fato geralmente é muito útil. Além de corrigir apenas um erro ou omissão em uma mensagem de log, ele permite que você faça 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 apresentado na revisão atual) .

A propósito, não há perigo de perder informações. Os ganchos pré-revprop-change e post-revprop-change podem salvar um histórico das mensagens antigas, se você estiver realmente preocupado, ou enviar e-mails com o diff das mensagens de log (isso é mais comum, na verdade), para que haja uma trilha de auditoria.