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

288

Não há dúvida de que a maioria dos debates sobre ferramentas de programação se destine a escolha pessoal (pelo usuário) ou ênfase em design , isso é , otimizando o projeto de acordo com casos de uso específicos (pelo construtor de ferramentas). 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, portanto, escolhe o Emacs sobre TextMate , etc.

É menos comum que uma tecnologia recém-introduzida seja genuína e comprovadamente superior às opções existentes.

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

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

Eu posso pensar em uma série de vantagens do Git sobre o Subversion (e que na maioria das vezes abstraem as vantagens do VCS distribuído sobre o centralizado), mas não consigo pensar em um exemplo - alguma tarefa (isso é relevante e surge em um fluxo de trabalho normal dos programadores) que o Subversion faz melhor que o Git.

A conclusão somente que tirei disso é que não tenho nenhum dado - não que o Git seja melhor, etc.

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

    
por doug 26.12.2013 / 00:17
fonte

20 respostas

205

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 .
por 23.06.2017 / 10:23
fonte
131

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.

    
por 26.12.2013 / 00:26
fonte
51

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.

    
por 26.12.2013 / 00:23
fonte
31
  • 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
por 26.12.2013 / 00:35
fonte
24

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.

    
por 26.12.2013 / 00:33
fonte
22

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.
por 30.09.2011 / 23:41
fonte
22

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.

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 equipamento de alta tecnologia. Eu apareço com um único rifle, sete balas e um canivete. Se eu precisar de mais de sete rodadas, então estou fazendo algo errado, e faço o mesmo que qualquer outra pessoa.

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.

    
por 26.12.2013 / 00:25
fonte
20

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.

    
por 30.09.2011 / 13:43
fonte
18

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.

    
por 26.12.2013 / 00:38
fonte
16

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.)

    
por 26.12.2013 / 00:29
fonte
14

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.

    
por 26.12.2013 / 00:31
fonte
11

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)
por 26.12.2013 / 00:37
fonte
8
  • 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.
por 16.11.2013 / 16:57
fonte
6

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.

    
por 07.01.2013 / 19:40
fonte
5

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.

    
por 01.10.2011 / 11:51
fonte
4

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.

    
por 01.10.2011 / 02:33
fonte
3

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 .

    
por 26.03.2013 / 18:20
fonte
2

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.
por 26.12.2013 / 00:43
fonte
1

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.

    
por 30.09.2011 / 22:32
fonte
-1

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.

    
por 17.11.2013 / 20:34
fonte