Pergunta

Meu atual local de trabalho está em transição, uma nova propriedade assumiu, as coisas estão finalmente sendo padronizadas e as diretrizes adequadas estão sendo aplicadas.

Mas ainda estamos usando o VSS, realmente não há nenhuma razão para usá-lo, a não ser o que foi configurado inicialmente.Não usamos o Visual Studio ou qualquer ferramenta que realmente exija isso especificamente.

Qual seria o melhor argumento que posso apresentar para ajudar a convencê-los de que ir para algo como o Subversion seria uma solução muito melhor, no longo prazo.

Foi útil?

Solução

O VSS depende totalmente dos clientes para gerenciar o banco de dados.Se um cliente interromper a conexão no meio de uma gravação na rede no momento errado, seu arquivo será descartado no servidor.Não apenas a dica, mas toda a história.Espero que você tenha um bom backup.Eu já passei por isso.São más notícias.

O uso de VSS por VPN ou outras conexões remotas é péssimo.Ele está usando SMB para transferir os dados, e você precisa recuperar o arquivo e todos os seus deltas apenas para obter a dica.Nojento.

Eu vi o VSS começar a funcionar com 1 GB de dados.Erros de banco de dados, etc.MS (em algum lugar em um FAQ ou KB) diz que 2 GB é realmente o limite máximo de segurança.Não existem boas ferramentas de gestão (os clientes administram o asilo), então você não recebe nenhum aviso sobre isso.

Qualquer coisa com um processo de servidor para fornecer algum nível de transações e controle de integridade é uma solução superior.

Outras dicas

O melhor argumento teria que ser a razão pela qual você deseja que eles mudem para o subversão.:)

Não sei absolutamente nada sobre VSS, mas a frase "se não está quebrado, não conserte" me vem à mente.Você tem que mostrar aos seus gerentes que o VSS está quebrado e precisa ser consertado.Melhor ainda se você puder mostrar à administração como isso economizaria dinheiro.

@Adam Davis:Uhhh, na verdade, Adam, VSS é um sistema de controle de origem horrível.Ele tem um longo histórico de corrupção de histórico e perda de dados.É péssimo na fusão, não lida bem com vários desenvolvedores e é muito lento.Além disso, a história é pobre.A Microsoft realmente não oferece mais suporte, você notará que eles nunca o usaram para seu próprio desenvolvimento interno e agora nem o vendem em favor de uma solução mais moderna (VSTS).Resumindo, se você tiver que escolher entre VSS e qualquer outro tipo de controle de origem, escolha a alternativa.

Apenas examinando os recursos que um bom controle de origem traz:

  • capacidade de ver facilmente registros de quem fez o quê, quando e em que ordem, para quais arquivos
  • manter um histórico de versões anteriores de tudo
  • volte e reproduza facilmente uma versão específica de seus arquivos de qualquer versão anterior, para reproduzir mais facilmente bugs relatados em versões mais antigas
  • capacidade de recuperar código excluído ou remover alterações indesejadas, sem ter que se preocupar em perder dados no processo

Qualquer documento que comprove a mudança reduzirá custos.Caso contrário, gráficos e tabelas multicoloridos.Talvez uma apresentação em power point.

A internet está repleta de artigos bem escritos sobre as falhas do VSS.Eu consideraria isso um conjunto de evidências para me afastar do SAV.Encontre um requisito importante que o VSS não pode suportar (trabalho remoto, suporte em outros sistemas operacionais, integração de ferramentas) e use-o para resolver o seu problema.Você então precisa encontrar um sistema de controle de origem que corresponda bem aos requisitos da sua organização - você tem certeza de que o Subversion é esse sistema?Configure uma demonstração do sistema escolhido e use-a para provar seu valor.

Eu implementei essa mudança em um empregador anterior (primeiro no CVS e depois no SVN) e, embora tenha sido bem-sucedida, tivemos que construir muitos bits ao redor e confiar em muitos projetos de código aberto (às vezes não confiáveis) para obter todas as ferramentas que precisávamos.Em retrospectiva, eu deveria ter considerado tentar avaliar ferramentas profissionais como Perforce, Vault ou mesmo Team System.Tendo avaliado isso, eu poderia ter feito um julgamento de valor adequado sobre se o CVS/SVN valia seu preço “gratuito”.

ser capaz de lidar com ramificações e bifurcações é um começo.

Tente usar o subversion por um tempo em paralelo ao vss, você provavelmente encontrará muitos argumentos para convencer seu chefe.Do contrário, seu chefe está certo, não há motivo para mudar.

Leve-os ao Google por 'problema vss', 'corrupção segura de origem' ou simplesmente consulte a página do Wiki para ver isso.Isso deve convencê-los de que provavelmente não é algo viável a longo prazo para você apostar em uma parte tão vital do seu negócio.

Qual é o tamanho da sua equipe?(ou seja, quero dizer quantos membros, não se você é ou não um trapaceiro de salada) Quando você começar a ter mais de meia dúzia de usuários bastante ativos, o VSS vai lhe dar dores de cabeça.

Duvido seriamente que a Microsoft o use (na verdade, eles não usam uma variante personalizada do Subversion ou do CVS?) E você deve se perguntar - se a empresa não come sua própria ração para cães, por que você a comeria?

A resposta básica é que você deve defender que a mudança atende às necessidades do negócio.Por exemplo:

  1. menor custo de desenvolvimento
  2. cronograma mais curto (outro tom de # 1)
  3. mais apto para atender aos requisitos do processo (como rastreabilidade de requisitos de software ou reprodutibilidade de construção, etc.).

Defender estas questões também requer algo quantitativo, e não apenas "reduziremos os custos porque esta é a certo maneira de fazer isso!".

Uma coisa a observar é que é muito fácil para um desenvolvedor se convencer de que seria benéfico fazer a mudança sem primeiro passar pelos filtros básicos de negócios.Quando isso acontecer, você acabará com desenvolvedores insatisfeitos com suas ferramentas e duplamente frustrados porque acham que a administração não vai ouvir.Se você não conseguir marcar uma das coisas acima, não terá chance de persuadir a administração de nada (a menos que a administração seja incompetente, mas isso é outra questão).

Por que Subversion em vez de VSS?

  • Software grátis
  • Mais fácil de gerenciar
  • "check-ins" são atômico!
  • Fácil de ramificar e mesclar
  • Desenvolvimento contínuo (ou seja,VSS é um beco sem saída)
  • Melhores ferramentas para rastrear alterações e visualizar logs
  • Independente de conjunto de ferramentas e plataforma, mas também se integra a muitas ferramentas

Fiz a proposta ao meu gerente e foi muito fácil de vender.Achei muito mais fácil de usar, especialmente para ramificação (nosso projeto levou 5 horas para "compartilhar e fixar" no VSS e cada operação levou um tempo extra para ser concluída!).

Eu tenho escrito anteriormente sobre por que o VSS não é uma boa ideia.Você pode obter algumas informações com isso.Também Este artigo e Este conter mais informações.

O VSS 2005 encobriu algumas das falhas do 6.0, mas não de uma forma particularmente convincente.A mesma base de morte cerebral permanece.

Mesmo que não esteja falido, há um benefício potencial em migrar do VSS.Em primeiro lugar, e mais trivialmente, você não precisará comprar novas licenças VSS.Em segundo lugar, existem muitos exemplos de deficiências no produto VSS (algumas também reconhecidas pelos Estados-Membros).A curva de aprendizado para SVN é pelo menos tão baixa quanto para VSS, e se você tiver desenvolvedores mais satisfeitos com seu sistema de controle de origem, é mais provável que eles o usem cedo e com frequência.Isso se traduzirá em muito menos risco para sua empresa e é um bom benefício.

@Jasão:O VSS está quebrado.

Acho que o método mais poderoso para motivar uma mudança no VSS é apontar o quão crítico é o seu código-fonte.Assumir riscos com sua integridade não é uma escolha comercial sábia.

Acrescente que seus programadores são os criadores desse ativo e que tornar mais fácil para eles serem produtivos significa mais valor em seu ativo de código-fonte.Joel on Software sempre fala sobre como investir em seus programadores é uma grande vitória para sua empresa.

Todas as outras respostas aqui descrevem razões específicas que você pode apontar ao apresentar seu caso.

Além dos pontos técnicos dados em outras respostas, pode haver motivos não técnicos ocultos aos quais você deve estar preparado para responder:

Você deve investigar se sua empresa tem algum tipo de política contra (ou medo equivocado de) software de código aberto.Se a empresa ou seus advogados não entenderem os detalhes de quais licenças “infectam” o código proprietário e quais não, bem como o que você pode fazer com o código-fonte aberto que não afeta seu código proprietário, você irá têm dificuldade em fazer com que eles mudem de uma ferramenta proprietária para uma ferramenta de código aberto.(E você pode ter um trabalho educacional maior em mãos.)

Ao defender a mudança do proprietário (por exemplo,VSS) para código aberto (por exemplo,subversion), você também precisará estar preparado para defender a qualidade do código e a falta de qualquer necessidade de garantia ou outros direitos contratuais em relação ao código.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top