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

293

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.

doug
fonte
3
@jokoon: Eficiente em termos de quê? Certamente não a velocidade, pois até a Ethernet rápida é lenta em comparação com as operações locais.
maaartinus 30/09
4
Sempre achei que o Git era superestimado. É uma moda passageira, e os programadores não são impermeáveis ​​à moda passageira - apesar das muitas oposições a esse pensamento. Como todo mundo neste mundo, todo mundo quer o novo e brilhante brinquedo (Git). O Git pode ser bom - ou até ótimo para algumas pessoas - mas nunca foi melhor que o SVN ao pensar objetivamente.
usar o seguinte código
3
Eu pensei que o SVN ainda é bom de usar, a curva de aprendizado é boa, então o GIT.
Cheung
5
Esta questão foi colocada em espera recentemente como baseada principalmente em opiniões. Essa classificação está errada; note que a questão ficou em aberto por um longo tempo; que existem muitas perguntas sobre as virtudes do DVCS e que a pergunta não pergunta se é melhor (opinião), mas o que faz melhor. As diferenças não são de opinião, mas se o produto geral é - isso é complicado (mas não é o objetivo desta pergunta).
Eamon Nerbonne

Respostas:

207

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.
treecoder
fonte
55
"O Subversion faz isso de uma maneira" - pensei assim também, até começar o meu trabalho atual. No meu trabalho atual, meu chefe, que afirma não ter problemas de confiança, configurou o servidor para exigir o bloqueio. Nenhuma fusão acontece em nosso sistema. Os arquivos estão bloqueados no repositório e ninguém mais pode gravá-los sem o bloqueio. O controle de cima para baixo, para aqueles cujas constituições o exigem, é definitivamente algo que o svn faz melhor que o git.
Dan Ray
14
Uma vantagem do repositório central é a facilidade de backups. Se todo o código registrado estiver em um local e esse backup tiver um local externo, você não perderá tudo se o seu escritório queimar. Com um DVCS, a menos que você faça backups externos das máquinas do desenvolvedor, você perde tudo o que não foi enviado ao servidor com backup externo.
Paul Tomblin
94
Por que o git não pode ser usado de maneira centralizada? Basta ter um repositório central e seus desenvolvedores podem clonar, puxar e empurrar como fazem checkout, atualizar e confirmar.
David Thornley
29
@PaulTomblin - Dependendo do fluxo de trabalho, o Git pode fornecer backups melhores . Por exemplo, usamos repositórios particulares do github e eu frequentemente uso o meu código para destacar ramos. Se meus colegas de trabalho git fetch origintiverem, cada um deles terá um backup do meu código, juntamente com qualquer backup que o Github forneça. (Nós podar regularmente ramos incorporadas, tanto localmente quanto no Github.)
Nathan Long
52
Você parece sugerir que a central é mais segura para grandes empresas ou trabalho governamental. Isto simplesmente não é verdade. Se você possui uma cópia do código no seu computador, você tem uma cópia do código. Não importa se veio de um servidor central ou de um sistema de arquivos central que possui um repositório DVCS.
John Fisher
131

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.

johannes
fonte
11
Trabalhar com subárvores é IMHO, a única coisa que o SVN tem sobre o GIT. Em suma, diretórios vazios são bons, mas também não são necessários (e podem ser contornados). Se os submódulos git e a subárvore git fossem menos confusos, não haveria nada impedindo muitas pessoas de migrar para o GIT. As outras vantagens mencionadas por algumas pessoas se resumem à mentalidade (de desenvolvedor). Por exemplo, se você precisar de cima para baixo, tudo bem. Eu não teria trabalho para você.
Até
3
É engraçado como esses são os únicos tipos de coisas que se pode argumentar em favor do SVN (e outra de controle de versão centralizado)
dukeofgaming
1
Por que isso é engraçado? - Sistemas mais novos aprendem com sistemas mais antigos. Existe ainda um benefício com o RCS sobre o git: os arquivos de histórico podem ser facilmente editados manualmente e você pode ter ramificações por arquivo. Mas eolution envolve que os recursos são perdidos ...
Johannes
3
Ouvi falar de uma empresa de jogos que usa SVN sobre GIT exatamente por esse motivo - quando você está falando de um repositório com muitos GB de tamanho, ele se torna repentinamente importante!
James
18
A partir da versão 1.8.0 do git, agora você pode usar o git subtreecomando para realizar exatamente isso. A última vantagem do subversion é a poeira :) Detalhes aqui: github.com/gitster/git/blob/… Nota: Embora este seja um link para um projeto do github, o git-subtree agora faz parte da distribuição principal do git.
Carl
51

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.

Peter Mortensen
fonte
25
Ser mais fácil de grok é uma vantagem importante, pois isso aumenta a probabilidade de ser usado. O SVN é certamente muito melhor do que nenhum controle de versão e, se alguém é teimoso com relação aos modos antigos, talvez o SVN seja a melhor escolha para eles.
Jhocking
12
@jhocking: Eu não amo o SVN, mas se alguém me disser "Eu não gosto dessas coisas novas do DVCS, então vou ficar com o CVS", então eu definitivamente recomendo: é o caminho mais fácil para pelo menos parcialmente VCS sã ;-)
Joachim Sauer
4
@jhocking Novas maneiras nem sempre são as melhores para todas as circunstâncias. Isso lembra a velha história de que a NASA gastou milhões de dólares desenvolvendo uma caneta que pode escrever em 0g. Os cosmonautas, por outro lado, são feitos com lápis. Às vezes os modos antigos são melhores, agora desça meu gramado!
maple_shaft
25
@ maple_shaft, e às vezes não. snopes.com/business/genius/spacepen.asp
Peter Taylor
3
O grokked facilmente é altamente subjetivo e baseia-se amplamente em como você tenta ajustar o novo conhecimento ao que você já deve saber. Também faz muita diferença qual é a sua fonte de aprendizado. Se você estiver acessando as páginas de manual, boa sorte. Se você está sendo ensinado por um bom professor que já o critica, você já conseguiu. Descobri que o git fazia muito sentido depois de assistir a vários bons vídeos no YouTube. Se você obtém seu entendimento de alguém que já o destilou até o núcleo simples, tudo é mais fácil de entender.
warrent
32
  • 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
Lazy Badger
fonte
23
Não quebra seu cérebro? Quer me ensinar como mesclar facilmente ramificações com conflitos no SVN?
warrent
4
Ferramentas / front-ends "melhores", esse é um alvo em movimento. As ferramentas melhoram nos dois lados. Nenhum de nós sabe quais ferramentas estarão disponíveis daqui a alguns anos. Essa avaliação, 10 meses atrás, pode mudar facilmente com o tempo e pode ficar obsoleta agora. Eu preferiria ver respostas substantivas.
warrent
6
Conflitos de árvores? Verifica. Sim ou não para todas as opções? Não. O Svn foi projetado para enfurecer. Comando de cópia de trabalho limpa? Não. A reversão não pode limpar arquivos não versionados.
Warren P
1
Excluir tudo e fazer o check-out novamente limpará os arquivos não-versionados.
Jgmjgm # 28/17
Eu amo sua última idéia, Git quebrou meu cérebro: '(
Luke
24

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.

Dan Ray
fonte
A centralidade é uma questão de mito, não de fato. Ninguém pode me impedir de mudar nada. Com um CVC, eles podem me impedir de mudar algo centralmente. A mesma coisa em um dvcs. A palavra commit no cvcs conflita commit e push.
Warren P
@ JonathanHenson: essa definitivamente não é a única razão pela qual Torvalds odeia o SVN. O SVN pode ser centralizado e pode ser um CVS melhor, mas que dificilmente o torna um bom software. Torvalds odeia o CVS / SVN não porque eles estão centralizados, mas porque ele considera que eles são pateticamente um software ruim. Se ele está certo ou não, cabe a você decidir, mas viu o imenso sucesso do Linux (e do Android) - rodando em bilhões de dispositivos - e do Git - que praticamente está conquistando o mundo--, eu pensaria duas vezes antes de discordar dele. A palestra que Torvalds deu no Google no Git anos atrás é incrível.
Cedric Martin
ri muito. Seu gerente tem razão em ficar aterrorizado por não haver um sistema de backup adequado. Apenas dizer "mas é DVCS para que alguém tenha uma cópia" não voa - eu sei, quando vi o git usado em meu último lugar, eles literalmente não tinham cópias de alguns repositórios. Lembre-se, o bloqueio pode ser bom para algumas situações e o git falha nesse sentido - a menos que você tenha uma ferramenta mágica de mesclagem para imagens ou outros arquivos binários. O git realmente funciona apenas para arquivos de texto.
Gbjbaanb
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 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.
Grant Palin
fonte
1
"confirmar o esquema de numeração" só é possível se você tiver troncos canônicos. Caso contrário, qual deles obtém a numeração principal?
1
+1 ao número em svn. Este número é único. existem ferramentas para usar esse número como parte do número da versão do aplicativo xx.yy.zz.12882 em que 12882 é o número da versão svn. Se houver um problema de produção você pode pedir vor o VersionNumber e você tem a exata svn-revisão onde o software foi construído com
k3b
22

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.

maple_shaft
fonte
3
Realmente? Então eu sugiro que você dê uma olhada no fóssil .
Spencer Rathbun
7
não vamos soar o alarme com a menor possibilidade de controvérsia. Os tópicos importantes são geralmente os mais controversos e os que têm maior probabilidade de invocar opiniões fortemente defendidas. Portanto, "Esse tipo de pergunta" é importante e a possibilidade de uma resposta fora dos limites não é plausível para não publicá-la. Presumo que os usuários deste site sejam adultos. O que é mais o modo como meu Q foi redigido, se não era neutro, era deferência para o pessoal da subversão - respostas responsivas ao meu Q teriam que recitar vantagens da subversão sobre o git, e não o contrário.
doug
@SpencerRathbun, Obrigado! Vou ter que dar uma olhada nisso. Não é tanto o que eu amo o svn, mas tenho uma aversão ao git.
maple_shaft
10
@ Spencer - Pelo contrário, como usuário de ambos gite hg, eu sugiro mercurial para quem pensa que gité demais. O TortoiseHG seria muito familiar para qualquer pessoa acostumada ao TortoiseSVN (ele até compartilha as mesmas sobreposições do Explorer no Windows). É certamente muito mais fácil do que o VSS e eu ficaria surpreso se demorasse mais alguns segundos para configurar um repositório hg, confirmar o estado inicial e cloná-lo em uma unidade compartilhada.
Mark Booth
@ MarkBooth Conforme declarado na pergunta original, acho que é uma questão de desejos e necessidades. No meu local de trabalho atual, não havia repositório antes de eu chegar lá. Eu precisava de algo que tivesse todas, ou quase todas, as ferramentas de projeto que queria agrupar, fosse fácil de usar, mantivesse tudo em vez de deltas e funcionaria distribuído para equipes de 1 ou 2 pessoas em várias máquinas.
Spencer Rathbun
20

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.

Torre
fonte
2
Como o SVN os trata melhor? O Git considera cada arquivo um BLOB.
warrent
4
@ WarrenT por causa dos fluxos de trabalho, com o git você está ramificando e mesclando muito (ou por que se preocupar em usá-lo) e simplesmente não pode mesclar realisticamente binários. Portanto, você costuma colocar a propriedade "needs lock" em arquivos binários no SVN.
Gbjbaanb
1
Alguns binários podem (teoricamente) ser mesclados, por exemplo, um documento ODT.
Donal Fellows
18

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.

Peter Mortensen
fonte
1
Assembla (para qualquer apoiado SCM - SVN na lista) é melhor do que github, eu acho
preguiçoso Badger
há também SmartGit, GitXL, etc. agora, programas que tornam o uso maneira git mais simples
wirrbel
@LazyBadger, nunca ouvi falar disso.
Pacerier 25/03
16

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

Ian
fonte
8
Usar gitramificação e mesclagem não são operações complexas. Eu até uso ramificações em um projeto individual, mesmo quando não há requisitos para várias versões. Mantendo o trabalho, você não pode continuar no momento em uma ramificação, ramificando quando descobre que tentar outra solução pode ser muito melhor ... No entanto, concordo que gité um pouco mais difícil de aprender.
Maaartinus
Sempre que você precisar fazer correções de erros em versões antigas, precisará ramificar e mesclar.
1
Por que as pessoas não consideram a idéia de que mercurial é mais fácil do que svn ou git?
Warren P
Acho que parte disso é que, até recentemente, o SVN não suportava ramificações e mesclagens sem um custo muito alto, permitindo ao programador enfrentar mais os gerentes quando eles queriam continuar mudando o que alguém está trabalhando. Uma ferramenta precisa trabalhar dentro das políticas de uma empresa e também ajuda a moldar as políticas de uma empresa.
11263 Ian
14

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.

Peter Mortensen
fonte
git é a abordagem mais "filosófica" do controle de versão. você começa a pensar sobre a semântica de commits, ramos, etc Então, as pessoas que querem usar um VCS como um "backup" e ferramenta de distribuição têm mais dificuldade, mas git não é muito mais difícil
wirrbel
11

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)
alexandrul
fonte
8
  • 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.
Tim
fonte
+1 para o problema de autenticação. As confirmações do Git precisam ser assinadas e as assinaturas precisam ser verificadas, o que é difícil.
Christian
6

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.

GlenPeterson
fonte
2
Outros atingiram isso ao mencionar "controle gerencial de cima para baixo". Este é um elemento chave para o meu ambiente - temos certas áreas de nossos repositórios que precisam ser bloqueadas para somente leitura ou mesmo sem leitura para alguns grupos de usuários. Também precisamos ter um único local para o qual possamos apontar e dizer "esta é a cópia principal autorizada, se a sua cópia não corresponder ao que está aqui, não é oficial".
Alroc
1
O abençoado repositório do líder do projeto e dos tenentes está dando controle sobre quem pode se comprometer. O repositório Git publicado no servidor habilitado para http-auth (usando os mesmos módulos apache svn) faz autenticação e diz quem pode clonar / fazer checkout do quê. Claro, não é tão granular quanto as permissões de svn por diretório, mas para mim parece mais um microgerenciamento do que a necessidade real.
quer
@HubertKario - isso levanta a questão: "Seus melhores programadores devem passar o tempo checando o código de outras pessoas?" Na verdade, eu estou tão interessado na resposta a esta pergunta, que eu postei isso aqui: programmers.stackexchange.com/questions/181817/...
GlenPeterson
5

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.

calum_b
fonte
6
Mas o checkout / clonagem é uma operação rara. Na maioria dos cenários, o git é mais rápido que o subversion.
Rds
5
git clone --depth=1é seu amigo, se você não se importa para a história
Hubert Kario
4

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.

jokoon
fonte
Você pode explicar o exemplo da indústria de jogos?
22415
3

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.

William Payne
fonte
2

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.
Shiba
fonte
1
+1 para o número 1. Compare os diagramas SVN vs GIT aqui steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git
s_t_e_v_e
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 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.

Sean McMillan
fonte
-1

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.

Karl Fogel
fonte
1
isso também é fácil de fazer no git; por exemplo, git --amend; Outra maneira de fazer isso é através do git reset --soft HEAD ^, que apenas retrocede, mas não altera o índice, e assim você pode editar / reescrever a mensagem de confirmação.
doug
Oi, doug. Sim, você pode fazer isso no seu repositório local, mas eu estou falando sobre isso depois que você promoveu a mudança em outro lugar - "git commit --amend" não ajuda muito nessa época. No SVN, você pode editar a mensagem de log no servidor central, precisamente porque existe um conceito de servidor central. Isso é o que eu quis dizer com "impossível por design em sistemas descentralizados". Vou editar minha resposta para deixar isso mais claro.
perfil completo de Carlos Fogel
1
Eu amo como "você pode mexer com a história" é supostamente um recurso . Eu consideraria um erro se não fosse intencional.
cHao 13/01