O SVN está fora de moda? [fechadas]


9

Faz apenas alguns anos desde que eu migrei do Visual Source Safe para o SVN. E o SVN para mim ainda é "WOW! Eu posso fazer muitas coisas! O SVN é tão legal!"

Mas muitas pessoas ao meu redor continuam dizendo "SVN? Sério? Meh ..."

E há tantos que estou preocupado. Devo mudar minha equipe para o Git / Mercurial ou alguma outra coisa chique? Eu sei que pareço ridículo e a resposta óbvia seria "fique com o que funciona para você". O SVN funciona para mim ... Mas toda vez que crio um novo projeto no meu repositório, fico me perguntando - pode ser que esse seja o momento de mudar?

Então ... SVN é realmente tão ruim assim? Perco uma grande oportunidade ao continuar com ela?


Isso pode ser uma leitura interessante: stackoverflow.com/questions/161541/svn-vs-git
Fouronnes

Você é um desenvolvedor independente?
TeaDrinkingGeek

6
Eu sempre usei o GIT. Agora eu tenho que usar o SVN no trabalho ... ... ... ... ... ... ... ... RAGE.
precisa

@TeaDrinkingGeek: O OP diz "Devo mudar minha equipe ...", então acho que há mais do que apenas o OP envolvido (a menos que você conte uma equipe de uma por equipe - mas geralmente não é chamado de "minha equipe" )
FrustratedWithFormsDesigner

lol desculpe companheiro, os olhos ficam um pouco borrados depois de 12 horas no laptop. :)
TeaDrinkingGeek

Respostas:


8

Depende inteiramente do uso.

Se você tem uma equipe de pessoas em uma sala e eles fazem a maior parte do trabalho lá, se você já possui um processo de compilação e implantação e se não deseja compartilhar amplamente seu código com as pessoas (como faria com um projeto de código aberto), então não se preocupe.

Troquei talvez de um ano atrás do Subversion para o git. O Git é perfeitamente adequado para esse caso de uso principalmente local, mas onde realmente brilha é o desenvolvimento distribuído. Utilizado localmente, é bom ter o github como um backup remoto e uma bonita interface da web para o código, e facilita a participação dos contratados. Mas não estou conseguindo muito disso agora que não estava conseguindo do Subversion.


8

Não se deixe levar pelo fluxo constante de hipopótamos. Você tem algo que funciona, continue usando-o até que haja um requisito comercial que seja melhor atendido com outra coisa (não, um novo sistema de controle de fonte brilhante ou linguagem de programação a cada poucos meses, sempre que algo "novo e aprimorado" for sugerido, NÃO vai para atender aos requisitos da sua empresa melhor do que o que você está usando agora).

Se o SVN funciona para sua organização, não há, portanto, motivo para investir o dinheiro / tempo / esforço necessário para mudar para outra coisa, por mais que algumas pessoas desejem, porque é novo e brilhante.

E não, essa não é (como JBK pensa) uma decisão que deve ser "da equipe", é uma decisão que cabe à gerência depois de consultar todas as partes interessadas (o que inclui pelo menos seus administradores de sistema). É uma decisão comercial gastar dinheiro mudando sua pilha de tecnologia, não uma decisão técnica.


Eu votaria em você um milhão de vezes, se pudesse.
HLGEM

5

Acredito que nunca se deve tomar decisões por ignorância. Se você não sabe o que está perdendo, tente sair por tempo suficiente até saber, então pode tomar uma decisão informada. O salto para o controle distribuído não pode realmente ser compreendido sem experimentá-lo e abandonar alguns hábitos antigos enquanto você o faz. A maior parte do poder do DVCS é que você pode criar quantas ramificações quiser, por qualquer motivo que desejar. Se você experimentá-lo há um mês e não tiver criado pelo menos cinco filiais, não o testou em seus próprios termos. Este é o erro da maioria das pessoas que não "entendem" o git. Depois disso, se você voltar ao svn, pelo menos você saberá os motivos.


5
Sou fortemente a favor de tomar a maioria das decisões por relativa ignorância. Você sugere que ele leve um mês para experimentar o git. Isso é trabalho de verdade. Ele só deve fazer isso se houver algum motivo para acreditar que isso tornará sua situação muito melhor. Caso contrário, provavelmente há outra coisa em que ele deveria passar o mês de experimentação. Por exemplo, redis, mongo, rails ou node.js ou BDD, uma das novidades igualmente interessantes.
William Pietri

Mas o Git é uma novidade nova. E a experiência de muitos usuários do Git sugere que a situação ficará muito melhor.
Kyralessa 2/08

3

Eu não usei o Git, mas usei o Mercurial e realmente não vejo qual é o problema. Parece muito com o SVN, exceto que coisas básicas como check-in e check-out são mais complicadas (requer duas etapas em vez de uma). Em troca, é suposto fazer muitas coisas mais avançadas que eu nunca precisei fazer muito mais simples. Minha reação às alegações de que o DVCS é de alguma forma inerentemente superior é basicamente: "OK, com certeza, vou acreditar na sua palavra", e então continuo com o SVN, que funciona muito bem para mim.


O grande problema do DVCS é que você pode fazer todo o seu trabalho "offline". Esse recurso impõe a exigência de que o DVCS possua um poderoso mecanismo de mesclagem capaz de lidar com rebasing e ramificação; o tipo de tarefas que simplesmente não são possíveis com um VCS centralizado. A superioridade reivindicada pelas pessoas vem dos fluxos de trabalho ativados, e não da superioridade técnica. Se você não usa ou precisa desse tipo de fluxo de trabalho, tudo bem também.
greyfade

11
Isso ocorre porque o check-in e o check-out não existem no DVCS. Você está usando o hg como um substituto do SVN, em vez de usar o hg da maneira que deveria ser usado. O mesmo se aplica a qualquer DVCS.
alternativa

@ Mathepic: Bem, você pode alterar o nome, se quiser, mas o conceito fundamental de transferência de dados entre a cópia de trabalho local e o repositório oficial existe em qualquer sistema de controle de origem.
Mason Wheeler

11
não, não tem. Não existe tal operação em um DVCS.
alternativa

3
sim, existe - o ponto de um repositório central de envio da versão 'master' é um caso de uso muito válido, seja para backup, servidor de compilação, gerenciamento de versões ou apenas uma maneira de coordenar melhor entre as equipes.
Gbjbaanb

-2

A resposta óbvia aqui é permitir que a equipe decida e tenha uma discussão sobre qual é a melhor opção para todos, para que não seja alguém que dê as ordens no vácuo. Pode haver várias opiniões e preocupações a serem abordadas, mas eu prefiro sugerir uma resposta de consenso em vez de tentar ser ditatorial sobre o que usar.


3
Você tem alguma idéia do custo em várias horas de mudar de um sistema de controle de origem para outro ou o risco de perder coisas no processo se alguém novo no novo sistema cometer um erro na conversão de código existente? NÃO é uma decisão da equipe, é uma decisão comercial e só deve ser tomada se você tiver necessidades reais que o seu sistema atual não pode atender.
HLGEM
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.