Pergunta

Estou programando há mais de 10 anos para o mesmo empregador e o único controle de código-fonte que usamos é o VSS.(Desculpe - era isso que eles tinham quando comecei).Só existimos alguns de nós;dois agora e geralmente trabalhamos sozinhos, então o VSS funcionou bem para nós.Então, eu tenho duas perguntas:1) Devemos mudar para algo como Subversion, git, TFS, etc., o que exatamente e por quê (por favor)?2) Estou além de toda esperança e destinado à condenação eterna porque o VSS me corrompeu (como diz Jeff)?

Uau - obrigado por todas as ótimas respostas!

Parece que devo esclarecer algumas coisas.Somos uma loja MS (parceiro Gold) e fazemos principalmente trabalhos em VB, ASP.NET, SQL Server, sharepoint e Biztalk.Eu tenho graduação em CS, então fiz assembly x86 C, C++ em DEC Unix e Slackware Linux em um "tempo fora da mente" ...

Minha preocupação com o VSS é que agora estou trabalhando muito mais em uma VPN e o desempenho do VSS é ruim e temo que nosso banco de dados VSS versão 5 com mais de 10 anos seja escolhido ...Existe o serviço LAN que supostamente acelera as coisas, mas nunca o usei e não tenho certeza se ajuda com a corrupção - alguém já usou o serviço VSS LAN?(novo no VSS 2005)

Foi útil?

Solução

Eu provavelmente escolheria o Subversion, se fosse você.Sou totalmente fanático por Git neste momento, mas o Subversion certamente tem algumas vantagens:

  • simplicidade
  • abundância de ferramentas interoperáveis
  • comunidade ativa e solidária
  • portátil
  • Tem uma integração muito boa com o shell do Windows
  • integra-se ao visual studio (eu acho - mas certamente através de terceiros)

O Git tem muitas, muitas outras vantagens, mas as acima tendem a ser aquelas com as quais as pessoas se preocupam quando fazem perguntas gerais como as acima.

Editar:a empresa para a qual trabalho agora usa o servidor VisualSVN, que é gratuito.Isso torna a configuração de um repositório Subversion em um servidor Windows estúpida e simples, e no cliente estamos usando o TortoiseSVN (para integração com shell) e o AnkhSVN para suporte ao Visual Studio.É muito bom e deve ser bastante fácil de ser aprendido até mesmo pelos usuários do VSS.

Edição dos últimos dias:Então...quase oito anos depois, eu nunca recomendaria o Subversion a ninguém por qualquer motivo.Eu realmente não me retiro, por si só, porque acho que meu conselho era válido na época.No entanto, em 2016, o Subversion não mantém quase nenhuma das vantagens que costumava ter sobre o Git.As ferramentas para Git são superiores (e muito mais diversificadas) ao que já foram e, em particular, há o GitHub e outros bons provedores de hospedagem Git (BitBucket, Beanstalk, Visual Studio Online, apenas na minha cabeça).O Visual Studio agora tem suporte imediato ao Git e é realmente muito bom.Existem até módulos do PowerShell para oferecer uma experiência mais nativa do Windows aos habitantes do console.O Git é ainda mais fácil de configurar e usar que o Subversion e não requer um componente de servidor.O Git se tornou tão onipresente quanto qualquer ferramenta pode ser, e você realmente estaria apenas se enganando se não o usasse (a menos que você realmente queira usar algo que não seja do Git).Não entenda mal - não sou eu que odeio o Subversion, mas sim que reconheço que é uma ferramenta de outra época, mais ou menos como uma navalha para fazer a barba.

Outras dicas

Parece que o SubVersion é o vencedor aqui.Eu faria um favor a si mesmo e usaria Servidor VisualSVN.É gratuito e vai lhe poupar muitas dores de cabeça na instalação.

Se você está acostumado com a forma como o VSS funciona, dê uma olhada (sem trocadilhos) Cofre do Sourcegear.É uma excelente maneira de migrar do VSS, pois ele vem com integração IDE e suporta check-out/check-in, mas quando estiver pronto e se sentir confortável, você também pode passar para o estilo de programação edit update commit encontrado no SVN.

É gratuito para desenvolvedores individuais, roda em IIS e é construído em .net, portanto deve ser uma pilha bastante familiar para você mudar.

Faça o que fizer, não mude por mudar.

Se estiver funcionando para você e você não estiver tendo problemas com isso, não vejo motivo para mudar.

Pelo que vale, o Perforce é uma opção potencial se você realmente se limitar a 1 ou 2 usuários.Os documentos atuais dizem que você tem 2 usuários e 5 clientes sem precisar começar a comprar licenças.

Você pode ter motivos para mudar para forçosamente, dependendo do seu fluxo de trabalho e se precisar ramificar da maneira que forçosamente faz isso.Não sendo muito familiarizado com alguns dos outros produtos mencionados aqui, não posso dizer como se compara necessariamente no departamento de recursos para coisas como ramificação, etc.

É rápido e tem sido sólido para nós (mais de 300 desenvolvedores em uma base de código com mais de 10 anos).Armazenamos vários T de informações e tem sido bastante responsivo.Com um pequeno número de usuários, duvido que você tenha muitos problemas de desempenho, supondo que tenha um bom hardware para seu servidor.

Tendo usado o VSS antes, acredito que você pode obter tantos benefícios de um sistema SCM melhor que a troca deve ser considerada independentemente de você ter corrupção ou não.A ramificação por si só pode valer a pena para você.Um verdadeiro modelo cliente/servidor, interfaces melhores (programaticamente e linha de comando) são algumas outras coisas que podem realmente ajudar a melhorar seu fluxo de trabalho e ajudar um pouco na produtividade.

Em resumo, minha visão do Perforce é:

  • É rápido e bastante confiável
  • Muitas ferramentas de cliente multiplataforma (Windows, Unix, Mac, etc.)
  • é gratuito para 2 usuários e 5 clientes
  • Integra-se ao estúdio de desenvolvimento (e outras ferramentas)
  • Possui um sistema de ramificação poderoso (que pode ou não ser adequado para você).
  • Possui várias interfaces programáveis ​​(python, perl, ruby, C++)

Certamente YMMV - eu apenas ofereço esta alternativa como algo que pode valer a pena investigar.

Recentemente comecei a usar Mercurial para alguns dos meus trabalhos.É um sistema distribuído como o Git, mas parece mais fácil de usar e tem muito melhor suporte no Windows, o último dos quais foi crucial para mim.

Com o controle distribuído do código-fonte, cada usuário possui uma cópia local completa do repositório.Se você é a única pessoa trabalhando em um projeto, como costuma dizer, isso pode simplificar muito as coisas, já que você apenas cria seu próprio repositório e faz todos os seus commits, etc.localmente.Se você quiser trazer outros desenvolvedores mais tarde, você pode simplesmente enviar todo o conteúdo do seu repositório - versões atuais e todo o histórico - para outro sistema, seja em um servidor compartilhado ou diretamente na estação de trabalho de outro usuário.

Se você estiver trabalhando apenas com um repositório local, lembre-se de que também precisará de uma solução de backup, pois não há uma cópia de todo o seu código em um servidor compartilhado.

Acho que o Mercurial tem muitas outras vantagens sobre o Subversion, mas tem uma grande desvantagem que já foi mencionada como um ponto positivo do Subversion:há um grande quantidade de ferramentas e integrações de terceiros para o Subversion.Como o Mercurial não existe há muito tempo, a escolha é muito menor.No Windows parece que você precisa usar a linha de comando (minha escolha) ou o TartarugaHg Integração com o Windows Explorer.

VSS é horrível.Posso estar canalizando Spolsky (não tenho certeza se ele disse isso), mas usar VSS é na verdade pior do que não usar controle de origem.Apesar do nome, não é seguro.Cria a ilusão de segurança sem fornecê-la.

Sem o VSS, você provavelmente faria backups regulares do seu código.Com o VSS, você pensará: "Nossa, já está sob controle de origem.Por que se preocupar em fazer backup?" Ótimo até corrompe toda a sua base de código e você perde tudo.(Isso, aliás, aconteceu em uma empresa em que trabalhei.)

Livre-se do VSS o mais rápido possível e mude para uma solução real de controle de origem.

Não se preocupe com o VSS corrompendo você, preocupe-se com o VSS corrompendo seus dados.Não tem um bom histórico nesse departamento.

Faça backup com frequência se você não mudar para um sistema de controle de versão diferente.Os backups deveriam acontecer diariamente, mesmo com outros SCMs, mas são duplamente importantes com o VSS.

Gosto de usar o Subversion para meus projetos pessoais.Eu poderia analisar a lista de recursos e fingir que isso traz muitas coisas para a mesa que outros sistemas de controle de origem não trazem, mas há muitos bons por aí e as escolhas certas são realmente uma questão de estilo.Se você fizer check-in após cada pequena alteração (ou seja,um check-in por alteração de função), muitas pessoas poderão trabalhar no mesmo arquivo de origem com risco muito baixo de conflitos de mesclagem em praticamente qualquer coisa mas VSS (não uso o VSS há anos, mas pelo que me lembro, apenas uma pessoa por vez pode trabalhar em um arquivo.) Se isso nunca vai acontecer com você, sinto que o melhor curso de ação é use o que você sabe.VSS é melhor do que nenhum controle de origem, mas parece restritivo para mim atualmente.

Não acho que você esteja sem esperança porque está perguntando se seria melhor mudar;você está sem esperança quando a resposta é óbvia e você ignora as evidências.

Mesmo que você não altere os sistemas de controle de origem, você deve escolher um como SVN ou git e passar algumas semanas lendo sobre ele e fazendo um pequeno projeto usando-o;sempre ajuda afiar a serra.

Não concordo com as pessoas que dizem que se você não tem problemas é melhor não mudar.

Acho que SCM é uma das disciplinas que um bom desenvolvedor deve conhecer bem e, francamente, mesmo que você domine VSS, você estará apenas experimentando uma pequena fração das vantagens que uma boa ferramenta e estratégia de SCM podem trazer para você e sua equipe.

Obviamente, avalie e teste as alternativas primeiro em um ambiente de não produção.

No trabalho usamos o subversion com o TortoiseSVN - funciona muito bem, mas é filosoficamente diferente do VSS (não é realmente um problema se for só você, mas vale a pena estar ciente).Gosto muito do fato de todo o repositório ter um número de revisão.

Se pudesse escolher, provavelmente teria optado pelo Vault, mas na época meu orçamento era zero.

Estou olhando coisas para uso pessoal.Existem razões para usar o subversion e razões para usar algo completamente diferente.As alternativas que estou considerando são Vault (como antes, gratuito para uso único) e Bazaar.GIT Tive que descartar porque sou, descaradamente, uma pessoa do Windows e no momento o GIT simplesmente não é.

A natureza distribuída do GIT e a opção de check-ins privados/temporários (assumindo que entendi o que li) é atraente - daí minha observação do Bazaar.

Atualizar: Pesquisei e joguei mais e optei pelo Mercurial para uso pessoal, a instalação integrada com o TortoiseHg torna as coisas muito simples e parece ser bem visto.Ainda estou tentando descobrir como forçar um espelho automático de commits em um servidor e parece haver algumas pequenas limitações na função ignorar, mas está funcionando bem até agora...

Murph

Eu diria que fique com o que funciona para você.A menos que você esteja tendo problemas com o VSS, por que mudar?O Subversion é ótimo, embora um pouco complicado para começar a usá-lo.O TFS é muito melhor que o VSS, embora seja bastante caro para uma equipe tão pequena.Eu não usei o git, então não posso falar sobre isso.

usei o vss por anos até mudar para o svn há cerca de dois anos.minhas maiores reclamações sobre o vss eram o baixo desempenho da rede (esse problema pode ser resolvido agora) e o bloqueio pessimista de arquivos.O svn resolveu ambos, é fácil de configurar (eu uso o servidor collabnet e o cliente tortoisesvn, embora existam dois bons plug-ins do visual studio:visualsvn - comercial e ankhsvn - código aberto), fácil de usar e administrar e bem documentado.

é tentador dizer "se não está quebrado, não conserte", mas você aprenderia uma ferramenta de controle de origem mais moderna e, talvez mais importante, novas maneiras de usar o controle de origem (por exemplo,ramificações e fusões mais frequentes) que a nova ferramenta suportaria.

Se você tem apenas 2 pessoas e trabalha principalmente de forma independente, o git lhe dará muito mais flexibilidade, poder e será, de longe, o mais rápido para trabalhar.

No entanto, é uma dor de cabeça usar.Usando o VSS, você obviamente está programando para Windows - se estiver fazendo coisas da API Win32 em C, o git será uma curva de aprendizado, mas será bastante interessante.

Se a profundidade do seu conhecimento se estende apenas ao ASP e Visual Basic, basta usar o subversion.Caminhe antes de poder correr.

** Não estou tentando dizer que se você conhece apenas VB você é burro ou algo assim, mas esse git pode ser muito meticuloso e exigente de usar (se você usou o WinAPI em C você sabe tudo sobre exigente e meticuloso), e você pode querer uma introdução mais gradual ao SCM do que o git fornece

Se você é um show individual e estritamente uma loja da Microsoft, então Cofre SourceGear é definitivamente um excelente candidato para mudar também.

Características:

  • Gratuito para usuário único, ótimo para você
  • Ele usa o SQL Server como back-end, portanto, a confiabilidade dos dados é enorme
  • Possui check-ins atômicos, todos os arquivos com check-in ao mesmo tempo são organizados em um grupo e são chamados de changeset.
  • Integração com VisualStudio.
  • Possui ferramenta para importação do SourceSafe, portanto você pode manter seu histórico
  • O cliente se comunica com o servidor via HTTP, portanto o acesso remoto à fonte fora do escritório pode ser configurado com muita facilidade e bom desempenho, pois apenas transfere os deltas das alterações enviadas e recebidas.Você pode usar SSL para proteger a conexão.

Eu definitivamente consideraria isso como uma opção.

Se você deseja um ciclo de vida completo em um pacote, provavelmente desejará dar uma olhada no Visual Studio Team System.Requer um servidor, mas você pode obter um "Action Pack" da MS que inclui todas as licenças necessárias para o "Team Foundation Server Workgroup Edition" no Partner Center.

Com isso você obterá rastreamento de bugs, riscos e problemas, além de muitos outros recursos :)

  • Fonte de controle
  • Acompanhamento de itens de trabalho (requisitos, bugs, problemas, riscos e tarefas)
  • Relatórios sobre os dados do seu projeto (rastreamento de itens de trabalho, construção, check-ins e muito mais em um único qube)
  • Análise de código
  • Teste de unidade
  • Teste de carga
  • Análise de desempenho
  • Construção Automatizada
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top