Por que é melhor do que Git Subversion?

votos
393

Estou usando o Subversion por alguns anos e depois de usar SourceSafe , eu adoro Subversion. Combinado com o TortoiseSVN , eu realmente não posso imaginar como poderia ser melhor.

No entanto, há um número crescente de desenvolvedores, alegando que o Subversion tem problemas e que devemos estar se movendo para a nova geração de sistemas de controle de versão distribuído, como Git .

Como o Git aperfeiçoar Subversion?

Publicado 03/08/2008 em 23:38
fonte usuário
Em outras línguas...                            


30 respostas

votos
548

Git não é melhor do que Subversion. Mas também não é pior. É diferente.

A principal diferença é que ele é descentralizada. Imagine que você é um desenvolvedor na estrada, você desenvolve em seu laptop e você quer ter controle de origem para que você possa voltar 3 horas.

Com o Subversion, você tem um problema: no repositório SVN pode estar em um local que você não pode alcançar (em sua empresa, e você não tem internet no momento), você não pode cometer. Se você quiser fazer uma cópia de seu código, você tem que literalmente copiar / colar.

Com Git, você não tem esse problema. Sua cópia local é um repositório, e você pode se comprometer com ele e obter todos os benefícios do controle de origem. Quando você recuperar a conectividade para o repositório principal, você pode cometer contra ele.

Este parece ser bom no início, mas basta ter em mente a complexidade adicionada a esta abordagem.

Git parece ser o "novo brilhante, cool" coisa. É de nenhuma maneira ruim (há uma razão Linus escreveu para o desenvolvimento do Kernel do Linux depois de tudo), mas eu sinto que muitas pessoas saltar sobre o trem "Distributed Source Control" só porque é nova e é escrito por Linus Torvalds, sem realmente saber por que / se é melhor.

Subversion tem problemas, mas o mesmo acontece com Git, Mercurial, CVS, TFS ou qualquer outra coisa.

Edit: Então, esta resposta é agora um ano de idade e ainda gera muitas upvotes, então eu pensei que eu vou adicionar mais algumas explicações. No último ano, desde escrever isto, Git ganhou muita força e apoio, particularmente desde sites como GitHub realmente decolou. Eu estou usando tanto Git e Subversion hoje e eu gostaria de compartilhar algumas dicas pessoais.

Primeiro de tudo, Git pode ser realmente confuso no início, quando o trabalho descentralizado. O que é um controle remoto? e como configurar corretamente o repositório inicial? são duas questões que surgem no início, especialmente em comparação com simples "svnadmin criar" do SVN, "init git" do Git pode tomar os parâmetros --bare e --shared que parece ser a maneira "adequada" para configurar um sistema centralizado repositório. Há razões para isso, mas adiciona complexidade. A documentação do comando "check-out" é muito confuso para as pessoas mudando ao longo - a maneira "adequada" parece ser "clone git", enquanto "git checkout" parece mudar ramos.

Git realmente brilha quando você está descentralizada. Eu tenho um servidor em casa e um laptop na estrada, e SVN simplesmente não funciona bem aqui. Com SVN, eu não posso ter o controle de origem local, se eu não estou conectado ao repositório (Sim, eu sei sobre SVK ou sobre maneiras de copiar o repo). Com Git, que é o modo padrão de qualquer maneira. É um comando extra embora (git commit comete localmente, enquanto que git mestre push origem empurra o branch master para a "origem" remoto chamado).

Como dito acima: Git adiciona complexidade. Dois modos de repositórios criando, check-out vs. clone, cometer contra empurrar ... Você tem que saber que comanda o trabalho localmente e que trabalham com "o servidor" (eu estou supondo que a maioria das pessoas ainda como um "mestre-repositório central" ).

Além disso, a ferramenta ainda é insuficiente, pelo menos no Windows. Sim, há um Visual Studio suplemento, mas eu continuo a usar git festa com msysgit.

SVN tem a vantagem de que é muito mais simples de aprender: Não é o seu repositório, todas as alterações em relação a ele, se você sabe como criar, comprometer e check-out e você está pronto para ir e pode coisas captador como ramificação, atualizar etc. depois em.

Git tem a vantagem de que é muito mais adequado se alguns desenvolvedores não estão sempre conectados ao repositório mestre. Além disso, é muito mais rápido do SVN. E pelo que eu ouvi, ramificação e mesclagem de apoio é muito melhor (que é de se esperar, uma vez que estas são as razões principais que foi escrito).

Isso também explica por que ele ganha muito buzz na Internet, como Git é perfeitamente adequado para projetos Open Source: Apenas Fork-lo, confirmar as alterações para o seu próprio garfo, e depois pedir o mantenedor do projeto original para puxar suas alterações. Com Git, isso só funciona. Realmente, experimentá-lo no Github, é mágico.

O que vejo também são Git-SVN Pontes: O repositório central é um repo Subversion, mas os desenvolvedores localmente trabalhar com Git e da ponte, em seguida, empurra as suas alterações ao SVN.

Mas mesmo com esta longa disso, eu ainda mantenho a minha mensagem central: Git não é melhor ou pior, é apenas diferente. Se você tiver a necessidade de "Control Fonte Off-line" ea vontade de passar algum tempo extra aprendendo, é fantástico. Mas se você tem um controle de origem estritamente centralizado e / ou estão lutando para introduzir controle de origem, em primeiro lugar, porque seus colegas de trabalho não estão interessados, então a simplicidade e excelente ferramental (pelo menos no Windows) de brilho SVN.

Respondeu 03/08/2008 em 23:45
fonte usuário

votos
145

Com Git, você pode fazer praticamente qualquer coisa desligada, porque todo mundo tem seu próprio repositório.

Fazendo ramos e fusão entre os ramos é realmente fácil.

Mesmo se você não tem direitos de envio para um projeto, você ainda pode ter o seu próprio repositório on-line, e publicar "solicitações de envio" para seus patches. Todo mundo que gosta de seus patches pode trazê-los para o seu projeto, incluindo os mantenedores oficiais.

É trivial de desembolsar um projeto, modificá-lo, e ainda manter a fusão nas correções do ramo HEAD.

Git funciona para os desenvolvedores do kernel Linux. Isso significa que é muito rápido (tem que ser), e escalas de milhares de contribuintes. Git também usa menos espaço (até 30 vezes menos espaço para o repositório Mozilla).

Git é muito flexível, muito TIMTOWTDI (Há mais de uma maneira de fazê-lo). Você pode usar qualquer fluxo de trabalho que você quer, e Git vai apoiá-lo.

Finalmente, há GitHub , um ótimo site para hospedar seus repositórios Git.

Inconvenientes do Git:

  • é muito mais difícil de aprender, porque Git tem mais conceitos e mais comandos.
  • revisões não têm números de versão como na subversão
  • muitos comandos do Git são enigmáticas e mensagens de erro são muito user-hostil
  • falta-lhe uma boa GUI (como o grande TortoiseSVN )
Respondeu 04/08/2008 em 01:24
fonte usuário

votos
110

Outras respostas têm feito um bom trabalho de explicar os principais recursos do Git (que são grandes). Mas há também muitas pequenas maneiras que Git se comporta melhor e ajuda a manter minha vida mais sã. Aqui estão algumas das pequenas coisas:

  1. Git tem um comando 'clean'. SVN precisa desesperadamente este comando, considerando a freqüência com que vai despejar arquivos extras em seu disco.
  2. Git tem o comando 'bisect'. É legal.
  3. SVN cria diretórios .svn em cada pasta (Git só cria um diretório .git). Cada script que você escrever, e cada grep o fizer, terá de ser escrito para ignorar essas pastas .svn. Você também precisa de um comando inteiro ( "svn exportação") apenas para obter uma cópia sadia de seus arquivos.
  4. No SVN, cada arquivo e pasta pode vir de uma revisão ou ramo diferente. Na primeira, ele soa bom ter essa liberdade. Mas o que isso realmente significa é que há um milhão de maneiras diferentes para o seu check-out local a ser completamente asneira. (Por exemplo, se "svn switch" falhar a meio, ou se você digitar um comando errado). E a pior parte é: se você entrar em uma situação em que alguns de seus arquivos estão vindo de um lugar, e alguns deles de outro, o "svn status" irá dizer-lhe que tudo é normal. Você vai precisar de fazer "svn info" em cada arquivo / diretório para descobrir o quão estranho as coisas são. Se "git status" diz-lhe que as coisas são normais, então você pode confiar que as coisas realmente são normais.
  5. Você tem que dizer SVN sempre que você mover ou excluir alguma coisa. Git só vai descobrir isso.
  6. Ignorar semântica é mais fácil no Git. Se você ignorar um padrão (como * .pyc), ele será ignorado por todos os subdiretórios. (Mas se você realmente deseja ignorar algo para apenas um diretório, você pode). Com SVN, parece que não há nenhuma maneira fácil ignorar um padrão em todos os subdiretórios.
  7. Outro item que envolve ignorar arquivos. Git torna possível ter "privado" ignorar configurações (usando o arquivo .git / info / excluir), que não vai afetar ninguém.
Respondeu 26/09/2008 em 01:18
fonte usuário

votos
56

" Por que Git é melhor do que X " descreve os vários prós e contras de Git vs outros SCMs.

Resumidamente:

  • Git rastreia conteúdo ao invés de arquivos
  • Ramos são leves e fusão é fácil , e eu quero dizer realmente fácil .
  • É distribuído, basicamente cada repositório é um ramo. É muito mais fácil desenvolver em simultâneo e de forma colaborativa do que com Subversion, na minha opinião. Ele também faz desligada desenvolvimento possível.
  • Ele não impõe qualquer fluxo de trabalho , como visto no website acima ligado , há muitos fluxos de trabalho possíveis com Git. Um fluxo de trabalho de estilo Subversion é facilmente imitado.
  • Repositórios Git são muito menores em tamanho do arquivo de repositórios Subversion. Há apenas um diretório ".git", ao contrário de dezenas de repositórios "Svn" (note Subversion 1.7 e superior agora usa um único diretório como Git.)
  • A encenação área é incrível, ele permite que você veja as mudanças que você vai cometer, confirmar as alterações parciais e fazer várias outras coisas.
  • Stashing é inestimável quando você faz o desenvolvimento "caótica", ou simplesmente quer corrigir um erro enquanto você ainda está trabalhando em outra coisa (em um ramo diferente).
  • Você pode reescrever a história , o que é ótimo para a preparação de conjuntos de patch e corrigir seus erros ( antes de publicar os commits)
  • ... e um monte mais.

Há algumas desvantagens:

  • Não há muitas boas GUIs para isso ainda. É novo e Subversion tem sido em torno de muito mais tempo, então isso é natural, pois há algumas interfaces em desenvolvimento. Alguns bons incluem TortoiseGit e GitHub para Mac .
  • Parciais checkouts / clones de repositórios não são possíveis no momento (eu li que ele está em desenvolvimento). No entanto, não há suporte submodule. Git 1.7+ suporta checkouts esparsas .
  • Pode ser mais difícil de aprender, apesar de eu não achar que este é o caso (cerca de um ano atrás). Git melhorou recentemente a sua interface e é bastante amigável.

No uso mais simplista, Subversion e Git são praticamente o mesmo. Não há muita diferença entre:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

e

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Onde Git realmente brilha é ramificação e trabalhar com outras pessoas.

Respondeu 10/02/2009 em 05:18
fonte usuário

votos
54

Google Tech Talk: Linus Torvalds no git

http://www.youtube.com/watch?v=4XpnKHJAok8

página de comparação do Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion

Respondeu 03/08/2008 em 23:44
fonte usuário

votos
26

Bem, é distribuída. Benchmarks indicar que é consideravelmente mais rápido (dada a sua natureza distribuída, operações como diffs e logs são todos locais, então é claro que é incrivelmente mais rápida neste caso), e pastas de trabalho são menores (que ainda sopra minha mente).

Quando você está trabalhando em subversão, ou qualquer outro sistema de controle de revisão cliente / servidor, você cria essencialmente cópias em sua máquina trabalhando por check-out revisões. Isto representa um instantâneo no tempo do que o repositório se parece. Você atualizar sua cópia de trabalho através de atualizações, e você atualizar o repositório via commits.

Com um controle de versão distribuído, você não tem um instantâneo, mas sim toda a base de código. Quer fazer uma comparação com a versão 3 meses de idade? Não tem problema, a versão 3 meses de idade ainda está no seu computador. Isso não significa apenas as coisas são muito mais rápido, mas se você estiver desconectado do servidor central, você ainda pode fazer muitas das operações que você está acostumado. Em outras palavras, você não só tem um instantâneo de uma dada revisão, mas toda a base de código.

Você acha que Git levaria um monte de espaço no seu disco rígido, mas a partir de um par de benchmarks que eu vi, ele realmente leva menos. Não me pergunte como. Quero dizer, foi construído por Linus, ele sabe uma coisa ou duas sobre sistemas de arquivos, eu acho.

Respondeu 03/08/2008 em 23:47
fonte usuário

votos
22

Os principais pontos que eu gosto sobre DVCS são aqueles:

  1. Você pode cometer coisas quebradas. Não importa, porque outros povos não os verá até que você publicar. Publicar tempo é diferente de cometer tempo.
  2. Devido a isso você pode cometer mais vezes.
  3. Você pode mesclar Funcionalidades de completa. Este Funcionalidades de terá o seu próprio ramo. Todos os commits deste ramo estará relacionada com este Funcionalidades de. Você pode fazer isso com um CVCS porém com DVCS seu padrão.
  4. Você pode pesquisar o histórico (encontrar quando uma função alterado)
  5. Você pode desfazer um puxão se alguém estragar o repositório principal, você não precisa corrigir os erros. Apenas limpar a mesclagem.
  6. Quando você precisa de um controle de origem em qualquer diretório fazer: git inicialização. e você pode cometer, desfazendo as mudanças, etc ...
  7. É rápido (mesmo no Windows)

A principal razão para a relativamente grande projeto é a comunicação melhorada criado pelo ponto 3. Outros são bônus agradáveis.

Respondeu 04/09/2008 em 12:06
fonte usuário

votos
15

O engraçado é: I hospedar projetos no Subversion Repos, mas acessá-los através do comando Git Clone.

Por favor, leia Desenvolver com Git em um projeto do Google Code

Embora o Google Code nativamente fala Subversion, você pode facilmente usar o Git durante o desenvolvimento. Procurando por "svn git" sugere esta prática é generalizada, e nós também incentivá-lo a experimentar com ele.

Usando Git em um repositório SVN me dá benefícios:

  1. Posso trabalhar distribuídos em várias máquinas, comprometendo e puxando a partir de e para eles
  2. Eu tenho um centro de backup/public repositório SVN para que outros possam verificar
  3. E eles são livres para usar Git para seu próprio
Respondeu 02/10/2008 em 14:05
fonte usuário

votos
11

Todas as respostas aqui são os esperados, programador centric, no entanto o que acontece se a sua empresa utiliza o controle de revisão fora do código-fonte? Há uma abundância de documentos que não são de código-fonte que beneficiam de controle de versão, e deve viver perto de código e não em outro CMS. A maioria dos programadores não funcionam isoladamente - que trabalham para empresas como parte de uma equipe.

Com isso em mente, comparar a facilidade de uso, tanto em ferramentas e treinamento do cliente, entre Subversion e Git. Eu não posso ver um cenário em que qualquer sistema de controle de revisão distribuída vai ser mais fácil de usar ou explicar a um não-programador. Eu adoraria ser provado errado, porque então eu seria capaz de avaliar git e realmente ter uma esperança de ele ser aceito por pessoas que precisam de controle de versão que não são programadores.

Mesmo assim, se solicitado pela administração por que devemos passar de um sistema centralizado para o sistema de controle de revisão distribuída, eu seria duramente pressionado para dar uma resposta honesta, porque nós não precisamos dele.

Disclaimer: eu me tornei interessado em Subversion cedo (cerca de v0.29) então obviamente eu sou preconceituoso, mas as empresas que eu trabalhei para desde aquela época estão se beneficiando com o meu entusiasmo porque eu tenho incentivado e apoiado o seu uso. Eu suspeito que isso é assim que acontece com a maioria das empresas de software. Com tantos programadores entrando na onda git, eu me pergunto quantas empresas vão perder os benefícios de usar o controle de versão fora do código-fonte? Mesmo se você tem sistemas separados para diferentes equipes, você está perdendo alguns dos benefícios, tais como (unificada) acompanhamento de questões de integração, aumentando simultaneamente os requisitos de manutenção, hardware e treinamento.

Respondeu 13/10/2009 em 08:01
fonte usuário

votos
9

Subversion ainda é um sistema de controle de versão muito mais usado, o que significa que ele tem um suporte melhor ferramenta. Você vai encontrar plugins SVN maduros para praticamente qualquer IDE , e há boas extensões explorador disponíveis (como TurtoiseSVN). Fora isso, eu vou ter que concordar com Michael : Git não é melhor ou pior do que Subversion, é diferente.

Respondeu 18/09/2008 em 19:44
fonte usuário

votos
8

David Richards WANdisco Blog em Subversion / GIT

O surgimento do GIT trouxe com ele uma raça de fundamentalistas DVCS - o 'Gitterons' - que pensar outra coisa senão GIT é uma porcaria. Os Gitterons parecem pensar engenharia de software acontece em sua própria ilha e muitas vezes esquecem que a maioria das organizações não empregam engenheiros de software sênior exclusivamente. Isso é ok, mas não é como o resto do mercado pensa, e estou feliz para provar isso: GIT, na última olhada tinha menos de três por cento do mercado, enquanto Subversion tem na região de cinco milhões de usuários e cerca de metade o mercado global.

O problema que vi foi que os Gitterons estavam disparando tiros (barato) no Subversion. Tweets como “Subversion é tão [lenta / baixa qualidade / restritiva / não cheira bem / olha para mim de um jeito engraçado] e agora eu tenho GIT e [tudo funciona na minha vida / minha esposa ficou grávida / Eu tenho uma namorada depois 30 anos de tentativas / I ganhou seis vezes correndo na mesa de blackjack]. Você começa o retrato.

Respondeu 17/09/2010 em 19:22
fonte usuário

votos
8

Uma das coisas sobre o Subversion que me irrita é que ela coloca sua própria pasta em cada diretório de um projeto, enquanto git só coloca um no diretório raiz. Não é que de um grande negócio, mas pequenas coisas como que se somam.

Claro, o Subversion tem Tortoise, que é [geralmente] muito agradável.

Respondeu 22/08/2008 em 16:24
fonte usuário

votos
7

Git também faz ramificação e mesclagem realmente fácil. Subversion 1,5 acabou de adicionar rastreamento da integração, mas Git é ainda melhor. Com Git ramificação é muito rápido e barato. Ele torna a criação de um ramo para cada novo recurso mais viável. Oh e repositórios Git são muito eficientes com espaço de armazenamento em comparação com Subversion.

Respondeu 09/08/2008 em 04:22
fonte usuário

votos
6

Fácil Git tem uma página agradável comparando o uso real de Git e SVN , que lhe dará uma idéia do que coisas Git pode fazer (ou fazer mais facilmente) em comparação com SVN. (Tecnicamente, isso é baseado no Easy Git, que é um invólucro leve no topo do Git.)

Respondeu 22/08/2008 em 16:19
fonte usuário

votos
6

É tudo sobre a facilidade de uso / passos necessários para fazer alguma coisa.

Se eu estou desenvolvendo um projeto único no meu PC / laptop, git é melhor, porque é muito mais fácil de configurar e usar. Você não precisa de um servidor, e você não precisa ficar digitando no repositório de URL quando você faz fusões.

Se fosse apenas 2 pessoas, eu diria que git é também mais fácil, porque você pode apenas empurrar e puxar de outra.

Depois de conseguir além disso, porém, eu iria para a subversão, porque naquele momento você precisa configurar um servidor 'dedicado' ou localização.

Você pode fazer isso tão bem com git como com SVN, mas os benefícios de git se superado pela necessidade de fazer medidas adicionais para sincronizar com um servidor central. Em SVN você acabou de cometer. Em git você tem que git commit, então git empurrar. O passo adicional fica chato, simplesmente porque você acaba fazendo tanto.

SVN também tem o benefício de melhores ferramentas GUI, porém o ecossistema git parece estar a aproximar-se rapidamente, então eu não me preocuparia com isso no longo prazo.

Respondeu 04/08/2008 em 00:38
fonte usuário

votos
5

Eu gosto de Git porque ele realmente ajuda desenvolvedor de comunicação para o desenvolvedor em um médio a grande equipe. Como um sistema de controle de versão distribuído, através de seu sistema de envio / recepção, que ajuda os desenvolvedores a criar um eco-sistema de código-fonte que ajuda a gerenciar um grande grupo de desenvolvedores trabalhando em um único projeto.

Por exemplo, dizer que você confia 5 desenvolvedores e só puxar os códigos de seu repositório. Cada um desses desenvolvedores tem sua própria rede de confiança de onde eles puxam códigos. Assim, o desenvolvimento é baseado em que o tecido de confiança de desenvolvedores onde a responsabilidade código é compartilhada entre a comunidade de desenvolvimento.

Claro que existem outros benefícios que são mencionados em outras respostas aqui.

Respondeu 05/10/2008 em 17:52
fonte usuário

votos
5

Git e DVCS, em geral, é ótimo para desenvolvedores que fazem um monte de codificação independentemente um do outro, porque todo mundo tem seu próprio ramo. Se você precisar de uma mudança de outra pessoa, no entanto, ela tem de se comprometer a sua repo local e, em seguida, ela deve empurrar o changeset para você ou você deve puxá-lo dela.

Meu próprio raciocínio também me faz pensar DVCS torna as coisas mais difíceis para QA e release se você fazer coisas como lançamentos centralizado. Alguém tem que ser responsável por fazer isso push / pull do repositório de todo mundo, resolver quaisquer conflitos que teriam sido resolvidas no inicial dedicar tempo antes, em seguida, fazer a compilação e, em seguida, tendo todos os outros desenvolvedores re-sync seus repos.

Tudo isso pode ser tratada com processos humanos, é claro; DVCS apenas quebrou algo que foi fixado pelo controle de versão centralizado, a fim de fornecer algumas novas conveniências.

Respondeu 04/08/2008 em 00:08
fonte usuário

votos
4

Eu acho que o Subversion é bom .. até que você comece a fusão .. ou fazer qualquer coisa complicada .. ou fazer qualquer coisa Subversion pensa é complicado (como fazer consultas para descobrir quais filiais mexeu com um arquivo particular, onde uma mudança realmente vem, a detecção de cópia e pastas , etc) ...

Não concordo com a resposta vencedora, dizendo que o principal benefício do GIT é trabalhar offline - é certamente útil, mas é mais como um extra para o meu caso de uso. SVK pode trabalhar offline também, ainda não há dúvida para mim que um a investir o meu tempo de aprendizagem in).

É apenas que é incrivelmente poderoso e rápido e, bem -após se acostumando com os conceitos - muito útil (sim, nesse sentido: user friendly).

Para mais detalhes sobre a história de fusão, consulte o seguinte: Usando git-svn (ou similar) * apenas * para ajudar com um svn merge?

Respondeu 27/07/2010 em 16:40
fonte usuário

votos
4

Algumas respostas já aludiu a isso, mas eu quero fazer 2 pontos explícita:

1) A capacidade para fazer submissões selectivos (por exemplo, git add --patch). Se o seu diretório de trabalho contém várias alterações que não fazem parte da mesma alteração lógica, Git torna muito fácil fazer um commit que inclui apenas uma parte das mudanças. Com Subversion, é difícil.

2) A capacidade de cometer sem fazer o público mudança. No Subversion, qualquer cometer é imediatamente público, e, portanto, irrevogável. Isso limita muito a capacidade do desenvolvedor para "cometer cedo, cometem muitas vezes".

Git é mais do que apenas um VCS; é também uma ferramenta para o desenvolvimento de patches. Subversion é apenas um VCS.

Respondeu 07/08/2009 em 15:59
fonte usuário

votos
3

Esta é a pergunta errada para se perguntar. É muito fácil se concentrar em verrugas de git e formular um argumento sobre por que a subversão é ostensivamente melhor, pelo menos para alguns casos de uso. O fato de que git foi originalmente concebido como um baixo nível de controle de versão conjunto de construção e tem uma interface orientada para o linux-desenvolvedor barroco torna mais fácil para as guerras santas a ganhar força e legitimidade percebida. proponentes Git bater o tambor com milhões de vantagens de fluxo de trabalho, que svn caras proclamar desnecessário. Em breve, todo o debate é enquadrado como centralizado vs distribuída, que serve os interesses da comunidade empresarial ferramenta de svn. Estas empresas, que normalmente colocar para fora os artigos mais convincentes sobre a superioridade da subversão na empresa,

Mas aqui está o problema: Subversion é um beco sem saída arquitetônica .

Considerando que você pode tomar git e construir um substituto subversão centralizado com bastante facilidade, apesar de ser em torno de mais do que o dobro do tempo svn nunca foi capaz de obter merge-tracking mesmo básica trabalhar em qualquer lugar próximo tão bem como ele faz no git. Uma razão básica para isso é a decisão de design para fazer ramos o mesmo que diretórios. Eu não sei por que eles foram desta forma originalmente, ele certamente faz checkouts parciais muito simples. Infelizmente, ele também torna impossível rastrear o histórico corretamente. Agora, obviamente, você deve para usar o Subversion convenções de layout repositório para separar ramos de diretórios regulares, e svn usa alguns heurística para fazer as coisas funcionarem para os casos de uso diário. Mas tudo isso é apenas papering sobre uma decisão de design muito pobre e limitando baixo nível. Ser capaz de um fazer uma comparação repositório-wise (em vez de diff diretório-wise) é a funcionalidade básica e fundamental para um sistema de controle de versão e simplifica muito as partes internas, tornando possível a construção de recursos mais inteligentes e úteis em cima dela. Você pode ver na quantidade de esforço que tem sido posta em estender a subversão, e ainda quão longe é a partir da atual safra de VCSes modernas em termos de operações fundamentais, como resolução de mesclagem.

Ora aqui está o meu coração de feltro e aconselhamento agnóstico para qualquer um que ainda acredita Subversion é bom o suficiente para o futuro próximo:

Subversion nunca vai pegar até as raças mais recentes do VCSes que aprenderam com os erros dos RCS e CVS; é uma impossibilidade técnica, a menos que reequipar o modelo de repositório a partir do zero, mas então não seria realmente svn não é? Independentemente de quanto você acha que não as capacidades de um VCS modernas, sua ignorância não irá protegê-lo de armadilhas do Subversion, muitos dos quais são situações que são impossíveis ou facilmente resolvido em outros sistemas.

É extremamente raro que a inferioridade técnica de uma solução é tão clara como é com svn, certamente eu nunca afirmaria tal opinião sobre win-vs-linux ou emacs-vs-vi, mas, neste caso, é tão controle de corte raso, ea fonte é uma ferramenta fundamental no arsenal do desenvolvedor, que eu sinto que deve ser declarado de forma inequívoca. Independentemente da exigência de usar svn por razões organizacionais, imploro a todos os usuários do SVN para não deixar a sua mente lógica construir uma falsa crença de que VCSes mais modernos são úteis apenas para grandes projetos de código aberto. Independentemente da natureza do seu trabalho de desenvolvimento, se você é um programador, você vai ser um programador mais eficaz se você aprender a usar VCSes melhor desenhados, seja Git, Mercurial, Darcs, ou muitos outros.

Respondeu 29/05/2011 em 18:30
fonte usuário

votos
3

Eu absolutamente amo ser capaz de gerenciar agências locais de meu código-fonte em Git sem turvando a água do repositório central. Em muitos casos, eu vou fazer o checkout código do servidor Subversion e execute um repositório Git local apenas para ser capaz de fazer isso. Também é ótimo que inicializar um repositório Git não polui o sistema de arquivos com um monte de pastas .svn irritantes em todos os lugares.

E, tanto quanto suporte de ferramentas do Windows, TortoiseGit lida com o básico muito bem, mas eu ainda prefiro a linha de comando, a menos que eu quero ver o log. Eu realmente gosto da maneira como Tortoise {Git | SVN} ajuda ao ler cometer logs.

Respondeu 10/02/2010 em 23:54
fonte usuário

votos
3

Graças ao fato de ele não precisa se comunicar com um servidor central constantemente, praticamente todos comando é executado em menos de um segundo (push obviamente git / pull / buscar são mais lentos, simplesmente porque eles têm que initalise conexões SSH). Ramificação é longe, muito mais fácil (um comando simples de ramo, um simples comando para mesclar)

Respondeu 30/08/2008 em 13:01
fonte usuário

votos
2

Para as pessoas que procuram um bom GUI Git, Syntevo SmartGit pode ser uma boa solução. Seu proprietário, mas livre para uso não comercial, funciona em Windows / Mac / Linux e ainda suporta SVN usando algum tipo de ponte git-svn, eu acho.

Respondeu 09/03/2011 em 15:05
fonte usuário

votos
2

Eric Sink de SourceGear escreveu série de artigos sobre as diferenças entre sistemas de controle de versão distribuído e Não-distribuídos. Ele compara prós e contras da maioria dos sistemas de controle de versão populares. Leitura muito interessante.
Os artigos podem ser encontrados em seu blog, www.ericsink.com :

Respondeu 13/10/2009 em 14:36
fonte usuário

votos
2

Subversion é muito fácil de usar. Eu nunca encontrei nos últimos anos um problema ou que algo não funciona como esperado. Também há muitos excelentes ferramentas da GUI e do apoio à integração SVN é grande.

Com Git você começa um VCS mais flexíveis. Você pode usá-lo da mesma maneira como o SVN com um repositório remoto onde você confirmar todas as alterações. Mas você também pode usá-lo principalmente desligada e só empurrar as mudanças ao longo do tempo para o repositório remoto. Mas Git é mais complexa e tem uma curva de aprendizagem mais íngreme. Eu encontrei-me na primeira vez que se comprometer com ramos errados, criando filiais indiretamente ou receber mensagens de erro com não muito informações sobre o erro e onde devo procurar com o Google para obter melhores informações. faz algumas coisas fáceis como substituição de marcadores ($ Id $) não funcionam, mas GIT tem um mecanismo de filtragem e um gancho muito flexível para mesclar próprios scripts e para que você obtenha todas as coisas que você precisa e mais, mas ele precisa de mais tempo e leitura da documentação ;)

Se você trabalha principalmente offline com seu repositório local você não tem backup se algo está perdido em sua máquina local. Com SVN você está trabalhando principalmente com um repositório remoto que também é ao mesmo tempo o seu backup em outro servidor ... Git pode trabalhar da mesma forma, mas este não era o objetivo principal de Linus ter algo como SVN2. Ele foi projetado para os desenvolvedores do kernel Linux e as necessidades de um sistema de controle de versão distribuído.

É Git melhor então SVN? Os desenvolvedores que precisa apenas de um pouco de história de versão e um mecanismo de backup têm uma vida boa e fácil com SVN. Os desenvolvedores que trabalham muitas vezes com ramos, testes mais versões ao mesmo tempo ou que trabalham principalmente fora de linha podem se beneficiar dos recursos do Git. Existem algumas características muito úteis como Stashing não encontrado com o SVN que pode tornar a vida mais fácil. Mas, por outro lado nem todas as pessoas terão todas as funcionalidades. Então eu não posso ver os mortos de SVN.

Git precisa de alguma documentação melhor e o relatório de erro deve ser mais útil. Também as GUIs úteis existentes são apenas raramente. Desta vez eu tenho encontrado apenas um GUI para Linux com apoio da maioria dos recursos do Git (git-cola). Integração Eclipse está funcionando, mas lançou o seu não oficial e não há nenhum site de atualização oficial (apenas alguns site de atualização externo com periódico constrói a partir do tronco http://www.jgit.org/updates ) Assim, a maneira mais preferido para usar Git este dias é a linha de comando.

Respondeu 13/10/2009 em 14:14
fonte usuário

votos
1

Porque eu acho que o Subversion é melhor do que Git (pelo menos para os projectos em que trabalho), principalmente devido à sua usabilidade e fluxo de trabalho mais simples:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Respondeu 22/10/2010 em 17:25
fonte usuário

votos
1

I foram habitando em terras Git ultimamente, e eu gosto para projetos pessoais, mas eu não seria capaz de mudar projetos de trabalho a ele ainda a partir do Subversion dada a mudança no pensamento do exigido de pessoal, sem nenhum benefício prementes. Além disso, o maior projeto corremos em casa é extremamente dependente de svn: externals , que, pelo que tenho visto até agora, não funciona tão bem e sem problemas em Git.

Respondeu 25/04/2010 em 22:35
fonte usuário

votos
1

http://subversion.wandisco.com/component/content/article/1/40.html

Eu acho que é bastante seguro dizer que entre os desenvolvedores, o Vs. SVN argumento Git tem sido travada por algum tempo agora, com todos tendo a sua própria opinião sobre o que é melhor. Este foi mesmo criado no das perguntas durante a nossa Webinar sobre Subversion em 2010 e além.

Hyrum Wright, nosso Diretor de Open Source e do Presidente para o Subversion Corporação fala sobre as diferenças entre o Subversion e Git, juntamente com outros sistemas de controle de versão distribuído (DVCS).

Ele também fala sobre as próximas mudanças no Subversion, como Cópia de Trabalho Next Generation (WC-NG), que ele acredita que vai causar um número de usuários do Git para converter de volta para Subversion.

Tenha um relógio de seu vídeo e deixe-nos saber o que você pensa por um ou outro comentário sobre este blog, ou postando em nosso fórum. O registo é simples e só vai demorar um pouco!

Respondeu 10/02/2010 em 19:51
fonte usuário

votos
1

Git no Windows é muito bem suportado agora.

Confira GitExtensions = http://code.google.com/p/gitextensions/

e o manual para uma melhor experiência com o Windows Git.

Respondeu 10/02/2010 em 17:29
fonte usuário

votos
1

Primeiro, o controle de versão concorrente parece ser um problema fácil de resolver. Não é de todo. De qualquer forma...

SVN é bastante não-intuitiva. Git é ainda pior. [Sarcástico-especulação] Isso pode ser porque os desenvolvedores, que, como problemas difíceis, como controle de versão concorrente, não tem muito interesse em fazer uma boa UI. [/ Sarcástico-especulação]

Apoiantes SVN acho que eles não precisam de um sistema de controle de versão distribuído. Pensei isso também. Mas agora que usamos Git exclusivamente, eu sou um crente. Agora controle de versão funciona para mim e para a equipe / projeto em vez de apenas trabalhando para o projeto. Quando eu preciso de um ramo, eu ramificar. Às vezes é um ramo que tem uma filial correspondente no servidor, e às vezes isso não acontece. Para não mencionar todas as outras vantagens que eu vou ter que ir estudar-se sobre (graças em parte à falta arcano e absurdo de interface do usuário que é um sistema de controle de versão moderna).

Respondeu 03/01/2010 em 13:45
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more