Razões específicas para continuar usando o Subversion? [fechadas]

22

Quero escolher um sistema de controle de versão para minha empresa. Até agora eu sei que tenho Git, Subversion e Mercurial.

Hoje em dia vejo que o Git é o mais usado, por isso fico pensando: haveria algum motivo específico para continuar usando o Subversion, ou devo ir diretamente para o Git?

version-control git svn user1179459
fonte
36
Ambos trabalham. O importante é se eles atendem aos seus requisitos, o que você não nos disse.
Matthew Flynn
6
Consulte Por que usar o SVN? Algum profissional escondido (no GIT / Mercurial / Bazaar) lá? no estouro de pilha.
detly
11
Em qual argumento você exclui o Mercurial?
Mouviciel
8
-1 para redação subjetiva (isca IMHO) e "Naqueles dias, vejo que o Git é o mais usado" - citação necessária. O Git é extremamente comum no mundo do código aberto, mas no espaço corporativo é muito mais raro. Os corpos realmente gostam da ideia de um repositório único, central e autoritário e demoram a mudar. No espaço corporativo, é mais provável que você veja um bom CVS antigo do que o SVN, mesmo assim, não importa um DVCS.
Keith
4
@RobinWinslow - SVN é diferente do Git. Mais adequado para algumas circunstâncias e mais adequado para outras. Pessoalmente, prefiro o DVCS em geral e você obviamente prefere o Git, mas ambos são opiniões subjetivas. Eles não têm valor, mas não pertencem a um site como este.
Keith

Respostas:

46

SVN não está absolutamente morto. Ainda está em uso extremamente amplo e não chegará a lugar algum tão cedo. O SVN é muito mais simples de usar que o controle de versão distribuído, especialmente se você não estiver executando um projeto distribuído que precise de controle de versão distribuído.

Se você tiver apenas um repositório central (que é tudo o que sua empresa precisará se ainda for pequeno o suficiente para sobreviver sem o controle de origem), é muito mais simples usar o SVN para interagir com ele. Por exemplo, com o SVN, você pode obter alterações do repositório ou confirmar suas alterações locais, com uma única operação, enquanto o HG e o Git requerem duas ou três etapas para realizar o trabalho equivalente.

E com as revisões recentes, o SVN corrigiu muitos problemas de desempenho que fizeram as pessoas preferirem HG e Git. É significativamente mais rápido agora do que há alguns anos atrás e, neste momento, não há realmente uma boa razão para olhar o HG ou o Git para o seu projeto, a menos que você realmente precise dos recursos avançados do controle de versão distribuído.

Mason Wheeler
fonte
16
Não concordo totalmente com sua estimativa, mas gostaria de acrescentar um ponto importante a favor do SVN: muitas pessoas no setor estão confortáveis ​​com o SVN, mas não conhecem o Git suficiente para trabalhar confortavelmente com ele. Se toda a sua equipe está acostumada ao SVN, a mudança para o Git pode custar bastante. (O oposto também pode ser verdade, é claro).
Joachim Sauer
8
Eu votaria essa dúzia de vezes, se pudesse. Muitas pessoas seguem a moda, mas realmente não pensam por que precisariam de controle de fonte distribuído.
eufórico
21
@Euphoric: Eu sei exatamente por que sempre quero controle de fonte distribuído em todos os projetos. Ele tem o importante efeito colateral de tornar a ramificação e a fusão simples, óbvias e confiáveis. O Subversion ainda está atolado nos casos de canto com ramificação, porque o modelo básico escolhido simplesmente o torna mais complicado.
Jan Hudec
18
O controle de versão distribuído não é um "modismo". É uma evolução do controle de origem, assim como o controle de versão simultâneo foi uma evolução sobre o paradigma de bloqueio de arquivos.
JesperE
6
@ MichaelBorgwardt, eu realmente fiz isso várias vezes. É muito mais fácil do que com o subversion, o fato de que tudo é local ajuda muito, não há necessidade de explicar a interação "cliente" e "servidor". O fluxo de trabalho em git ou hg é muito mais natural e intuitivo (se você ficar longe dos bits complicados, como a edição de histórico).
SK-logic
19

As ferramentas do cliente ainda não foram mencionadas. Você certamente pode fazer tudo com um script de linha de comando, mas a integração com a GUI pode ser um aumento real da produtividade.

Trabalhamos principalmente com o Visual Studio; a integração no IDE é definitivamente melhor com o SVN do que com o Git no momento. Isso pode mudar no futuro, mas eu certamente consideraria isso em sua decisão, tanto quanto o controle de versão funciona.

Assim como tudo o mais, um sistema de controle de versão não é um objetivo em si, apenas uma ferramenta para levá-lo aonde você está indo. Escolha o que o levará mais rápido, com base na sua situação.

njr101
fonte
Este é um bom argumento. Eu acho que uma das razões pelas quais as pessoas preferem o Git sobre o SVN é que o Git tem melhores ferramentas de CLI. Mas isso pode ser compensado com uma boa interface gráfica SVN de terceiros, como o TortoiseSVN no Windows.
eufórico
2
Essa é uma das razões pelas quais escolhemos o Mercurial (e o TortoiseHg) sobre o Git. As vantagens do controle de versão distribuído e ferramentas decente e integração IDE.
HappyCat
15

Sou fã do Git. Recentemente, tive que admitir que uma das desvantagens do Git é que ele identifica versões com hashes como opostas aos números de lançamento do svn. O número do release pode ser mais facilmente repassado por telefone ou algo assim.

E esse é o único profissional que posso imaginar. Se você realmente deseja confiar nesse recurso, pode tê-lo em um bazar VCS distribuído e / ou centralizado . No Git, existem tags que podem servir a esse propósito.

Enfim, eu simplesmente não conseguia imaginar o desenvolvimento sem a troca rápida de ramificação e a ocultação. Somente esses dois recursos superam o SVN, onde, até o momento, lembro que a mesma tarefa exigia a criação e o check-out de uma árvore inteira em diretórios separados para atingir o mesmo objetivo.

Os chamados "recursos avançados do controle de versão distribuído" vêm com o tempo e você não precisa aprendê-los desde o início. Não tenha medo deles. Eles estão aqui para ajudá-lo, não para atrapalhar. E não há problema em configurar um repositório central para um DVCS.

Rajish
fonte
1
Isso é discutível, o git precisa apenas de uma parte grande o suficiente do hash para poder desambiguar, geralmente algo ~ 6 caracteres é suficiente, e não o hash inteiro.
TC1
2
Na prática, você nunca passa o git hash por aí. Você pode usar qualquer prefixo exclusivo do hash, que geralmente possui de 6 a 7 caracteres.
JesperE
1
@JesperE: Sim, mas os números de versão SVN aumentam sequencialmente ao longo do tempo, enquanto os hashes do Git, mesmo se você os abreviar, também podem ser aleatórios.
9788 Keith Thompson
2

Com o SVN, você pode facilmente fazer check-out de partes de um repositório até o nível da pasta, enquanto que com o git, você obtém todo o repositório, incluindo todo o histórico.

Dependendo da situação, isso pode ter algumas vantagens para o SVN

(isso também tem algumas desvantagens, como o lixo ".svn" oculto na árvore de pastas).

Richard Nichols
fonte
3
nota: não há lixo .svn desde a v1.7 - agora está tudo armazenado em um único local.
Gbjbaanb
Isso não está correto - o git permite que você faça check-out apenas dos arquivos, sem o histórico, e também é possível fazer check-out de apenas partes dos arquivos repo - únicos, se desejar. É um pouco mais complexo que o svn, mas a capacidade está lá.
Benubird
2

"Se você tem uma tarefa que pode ser executada em seis horas, é melhor escrever uma ferramenta que faça isso em 20 minutos, mesmo quando a criação da ferramenta leva seis horas?"

O controle de versão distribuída é um animal diferente para enfrentar. Requer aprendizado substancial para cada desenvolvedor. Se você possui um buffer para acomodar o processo de aprendizado de cada desenvolvedor, deve passar para um bom sistema de controle de versão distribuído. Quando a fase de aprendizado terminar, o Controle de versão distribuído é muito melhor que o Controle de versão centralizado.

O controle de versão distribuído parece ser uma eventualidade. Está aqui para ficar por muito tempo, é melhor nos adaptarmos a ela mais cedo ou mais tarde. Lembro-me da mesma discussão quando o SVN era novo e as pessoas estavam acostumadas ao CVS, muitos argumentos foram dados para não usar o SVN, mas eventualmente o SVN se tornou o sistema de controle de versão mais popular.

Se a empresa estiver bem estabelecida com muito código-fonte no sistema de controle de versão existente, mudar para um novo sistema é uma grande tarefa, mas se a empresa for pequena ou iniciar, é muito fácil mudar para um novo controle de versão. Mas se você se ater a um controle de versão mais antigo (em uma nova configuração), atingirá o gargalo em algum lugar no futuro em que terá que, eventualmente, planejar uma migração de controle de versão.

Eu já vi muitos comentários profissionais do SVN, mas todos eles tendem a ser da natureza "SVN não é ruim", em vez de "SVN é melhor". Portanto, eu recomendo fortemente que você escolha um Controle de versão distribuído (como o Git) para o seu projeto.

EDIT Vantagens do GIT sobre SVN

  1. Nenhum servidor dedicado é necessário Na verdade, ambos podem ser usados ​​sem um servidor.
  2. Pode continuar o desenvolvimento mesmo sem uma conexão de rede.
  3. O gerenciamento de filiais é muito mais fácil.
  4. Melhor suporte das ferramentas de CI, como Bamboo

Alguém mencionou as ferramentas (para o visual studio) como um motivo para manter o SVN. http://gitscc.codeplex.com/ fornece suporte GIT para o Visual Studio.

Apeirogon Prime
fonte
6
SVN faz lidar com arquivos binários melhor então Git ou Hg.
Fake Name
2
"Você atingirá o gargalo em algum lugar no futuro onde terá que planejar uma migração de controle de versão ..." Desculpe, não posso concordar que esse seja um bom motivo para fazer a mudança hoje. Já trabalhei em muitos projetos em que essa abordagem leva a tornar as coisas mais complicadas do que precisam e o projeto é cancelado muito antes de tirar proveito desses benefícios futuros. Às vezes, bom o suficiente, é bom o suficiente. Atenha-se ao YAGNI e aceite o que faz o trabalho hoje. Haverá tempo suficiente para se preocupar com as migrações mais tarde. Pelo menos você ainda terá um projeto.
Njr101 03/09/12
2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Eu discordo completamente disso. Pode ter alguns benefícios percebidos em algumas circunstâncias, mas algo tão simples quanto o número da versão no svn legível por humanos é um benefício enorme em muitas organizações.
TZHX
1
@apeirogon - Tudo se resume ao que você vai colocar no repositório. O HEAD sozinho de um dos principais repositórios com os quais trabalho é de 11,1 GB! Se eu o tivesse em um repositório Git / bzr / hg, provavelmente levaria mais de 100 GB.
Fake Name
1
Obviamente, isso ocorre porque esse repositório específico está cheio de arquivos PCB e modelos 3D, todos com formato binário e pouco espaço. A recomendação aqui (Electronics.SE, por exemplo, para pessoas que armazenam arquivos de design de PCB, etc) é muito diferente, se for para alguém que armazena código-fonte.
Fake Name
1

haveria algum motivo específico para usar o Subversion naqueles dias

Além do suporte de ferramentas nos IDEs (que eu não uso) - na verdade não. É claro que o SVN pode ser mais familiar, mas esse é o único motivo, e eu achei o Hg e o Git muito fáceis (e muito rápidos) de aprender.

Sim, existem todos esses guias complexos que descrevem como o Git é trivial depois que você entende que os ramos são apenas endofuncores homeomórficos que mapeiam subvariedades de um espaço de Hilbert. 1 1

Eu não entendo isso. Mas você sabe o que? Não importa. Você não precisa conhecer nada disso para usar o Git.

Na maioria das vezes, o Git e o Hg são fáceis de usar e possuem vantagens definitivas sobre o SVN. É claro que o elefante na sala está se ramificando: os galhos funcionam apenas em Git e Hg. Por outro lado, no SVN eles são dolorosos na melhor das hipóteses e quebrados na pior (mesclando várias cabeças).

Claro que você ainda pode usar o SVN. Você ainda pode usar o Windows XP. No entanto, a maioria dos usuários que tentaram os dois concorda que uma das alternativas é muito superior.

1 Sim, entendi que isso é uma piada. Eu acho que.

Konrad Rudolph
fonte
Um tutorial Git com endofuncores homeomórficos mapeando subvariedades de um espaço de Hilbert? Eu preciso ler isso! Mas isso não se aplica a Darcs, que está escrito em Haskell (que eu considero endofuncor ) e inspirado na mecânica quântica (daí o espaço de Hilbert )? Realmente não consigo ver o que Git e HG têm a ver com essas coisas.
usar o seguinte código
@leftaroundabout É uma piada. A descrição nem é precisa (tanto quanto eu sei). É um riff sobre os muitos tutoriais que começam com “git branches são fáceis quando você percebe isso…” e, depois, há uma metáfora complexa específica de domínio.
Konrad Rudolph
1
Você já considerou que todos esses tutoriais excessivamente complicados existem por um motivo? E para que serve afinal? Eu nunca entendi a obsessão que o público do DVCS tem por ramificar e depois reintegrar um ramo para cada pequena coisa. Isso sempre me pareceu uma solução em busca de um problema. Reintegrar uma ramificação no SVN é difícil, porque isso é uma coisa realmente idiota e conceitualmente errada a ser feita , e eu realmente não encontro nenhum argumento que se refira a "nosso produto facilita muito a tarefa de fazer a coisa errada". muito persuasivo.
Mason Wheeler
1
Quanto a trabalhar em várias mudanças em paralelo, admito que é um pouco doloroso, mas a solução certa é a prateleira, que está planejada para o próximo lançamento do SVN. E na maioria das vezes, se você estiver trabalhando em várias alterações ao mesmo tempo (e principalmente se estiver fazendo isso de forma consistente!), Isso é evidência de um problema mais amplo que deve ser tratado no nível da organização, não ativado com novos Ferramentas. (Veja acima, re "nosso produto faz fazendo a coisa errada soooo muito mais fácil", e artigo clássico de Joel em comutação de tarefas humanas.)
Mason Wheeler
3
@KonradRudolph A fusão de ramificações de volta ao tronco funciona muito bem nas versões mais recentes do SVN. Está ficando cada vez melhor há vários anos, até onde está muito bom agora.
Adam Bruss 21/09/12