Um desenvolvedor deve ter permissão para usar o VSS, se preferir?


14

Apresentei o Mercurial ao meu departamento. Adoro, mas é a minha primeira experiência de controle de versão. Estou usando-o com o NetBeans PHP para desenvolvimento web.

Outro desenvolvedor que trabalha em aplicativos internos da empresa gosta de usar o Visual Source Safe e não deseja alternar. Ele trabalha em um ambiente do Visual Studio.

Todos os outros desenvolvedores compraram no Mercurial, exceto este. Na maioria das vezes, todos trabalhamos de maneira independente.

Estou tentando mover esse departamento na direção certa, configurei todo mundo com uma conta no Kiln, esperava que todos usassem o Fogbugz no caminho também (já que atualmente não há nenhum banco de dados de bugs sendo mantido). nunca usei o VSS, mas ouço coisas muito ruins sobre isso.

Seria melhor permitir que ele continuasse usando o VSS, se é o que ele prefere, ou seria do seu interesse levá-lo a bordo do Mercurial?


Você pode achar stackoverflow.com/questions/961878/… interessante.

Um desenvolvedor que usa seu próprio VCS privado parece perigosamente próximo a um desenvolvedor cujo código não está sendo adequadamente copiado. Você está fazendo backups (fora do local!) Do seu repositório Mercurial, espero. Isso cobre todos, exceto um de vocês. Você está fazendo o mesmo para o repositório VSS? Se algo der errado com esses backups, alguém notaria? Etc.
derobert

8
É como um desenvolvedor que quer sentar no vaso sanitário para programar, enquanto o resto dos funcionários usa cadeiras.
Muhammad Hasan Khan


1
Calma gente ('-') VSS não é tão ruim assim! Comecei com o VSS. Embora eu não use mais o VSS, não posso ser tão ruim quanto as pessoas imaginam (também não é ótimo). Pensei que colocar algum tipo de equilíbrio ...
Darknight

Respostas:


50

seria melhor apenas permitir que ele continuasse usando o vss se é isso que ele prefere

Não. Não faz sentido executar dois sistemas diferentes de gerenciamento de origem em paralelo. Isso desafia a própria idéia de que todos os desenvolvedores estejam conectados ao mesmo repositório e tirem todas as vantagens dele.

Um desenvolvedor único usando um sistema diferente sozinho se isola efetivamente da equipe. Mesmo que os projetos não se cruzem, ainda é uma coisa ruim a se fazer.

Os esforços duplicados de manutenção para ambos os sistemas são outro argumento aqui.

Acho que você deve usar sua autoridade ou encaminhar o problema ao gerenciamento para migrar rapidamente o conteúdo do VSS para o Mercurial e, em seguida, desligar o VSS.

PS Falando em VSS, é notório por perder check-ins ou danificar o código quando você menos espera. Funciona, mas dá nos nervos regularmente. Se você tiver uma alternativa melhor, evite o VSS.


42
NINGUÉM deve usar o VSS sob quaisquer circunstâncias. Seu nome é uma mentira. Nada no VSS é seguro.
CaffGeek

17
Concorde com isso e gostaria de adicionar algo que aprendemos: Não há benefício em usar o VSS que não seja rapidamente compensado pelo maior benefício de não usar o VSS.
precisa

+1 Obrigado, foi o que eu pensei também, só queria que outros entendessem antes de eu fazer um problema.
JD Isaacks

2
@ Ben: vai fazer, e quando as pessoas perguntam "Quem é Hoffstein?" Vou encará-los e exigir saber qual rocha eles escondidos sob durante a última década :)
Binary Worrier

2
Você daria a mesma resposta se a equipe estivesse usando SourceSafe ou TFS ou SVN e o desenvolvedor não autorizado estivesse usando Git ou Mercurial?
Kyralessa 6/10/11

16

De maneira alguma eu consideraria permitir que um desenvolvedor invasor usasse um sistema de controle de origem diferente do resto da equipe.

O controle de origem não é apenas para que eu possa encontrar versões anteriores do que fiz, mas para que outros possam encontrá-las (e a versão atual) também. Isso não é negociável. O que acontece quando ele sai ou é atropelado por um ônibus e ninguém mais tem acesso ao seu código (que pode até ser substituído por administradores de rede quando eles limpam sua máquina, sem saber que ele tinha seu próprio controle de origem lá?

Suponho que seu código de controle de origem possa estar apenas em sua máquina, pois ninguém mais está usando o VSS.) Um desenvolvedor que sugeriria algo assim não é profissional e isso me deixaria desconfiado de todo o seu trabalho. O que ele não quer que o resto de vocês veja?

Além disso, o VSS é notoriamente incorreto. O código dele nem é seguro lá.


10

Ninguém deve usar o VSS para começar.

Diga ao desenvolvedor para obter um plug - in do Mercurial para o Visual Studio.


Você tem experiência com o referido plugin?

Eu usei - funciona bem.
precisa saber é o seguinte

@ Thorbjørn Ravn Andersen: Não. Usamos a subversão no trabalho.
Dima

1
sem uma explicação, essa resposta pode se tornar inútil se outra pessoa postar uma opinião oposta. Por exemplo, se alguém postar uma declaração como "Todos devem ser incentivados a usar o VSS para começar. De qualquer maneira, evite usar o plug-in Mercurial para o Visual Studio". , como essa resposta ajudaria o leitor a escolher duas opiniões opostas? Considere editar ing-lo em uma melhor forma
mosquito

3

Todos devem estar no mesmo sistema de gerenciamento de origem. Além disso, seu objetivo final é também colocar todos no mesmo sistema de rastreamento de bugs. Você já fez a coisa certa ao encontrar uma solução totalmente integrada.

Se você está tendo problemas para fazê-los mudar, tente abordá-lo do ponto de vista da carreira. Se eles trabalharem em outro lugar, esse possível empregador provavelmente desejará ter alguma experiência trabalhando com uma configuração integrada de aplicativo de gerenciamento de bugs / fontes.


1
+1, mas não tenho tanta certeza de que esse é um ponto de venda; Encontrei muito mais empresas que não tinham idéia do que era o controle de origem, pensavam que o VSS era o controle total de todas as fontes ou usavam mal o controle de fontes do que aquelas que desejam ver uma configuração integrada. Inferno, a maioria dos que eu vi nem sequer usava aplicativos de rastreamento de bugs ou tinha algum "sistema de tarefas" interno que era extremamente básico.
Wayne Molina

+1 ao seu comentário. Estou vendo o mundo através de óculos cor de rosa e trabalhos publicados na Stack Careers novamente. Você está certo. Até a nossa loja não tinha esse material até que a equipe com a qual eu trabalhei começou a latir há cerca de 4 anos.
Mat Nadrofsky

3

Vai ecoar o que os outros disseram, já que é ruim permitir que ele use o VSS e não o Mercurial. No entanto, deixe-me interpretar o advogado do diabo e dizer que você pode deixar passar, e somente se, ele ainda se comprometer com o Mercurial para que outros possam acessar seu trabalho, se necessário. Não há nada IMO errado em usar suas ferramentas preferidas, desde que você não impeça que outras pessoas acessem o trabalho de que precisam. Obviamente, o VSS é um lixo, portanto não deve ser usado, não importa o que :)

Por exemplo, trabalho em uma empresa que usa SVN, mas não possui o repositório configurado corretamente (sem ramificações / tags / tronco, tudo é jogado apenas em um repositório) e isso causa alguns problemas que ninguém sabe como corrigir. Eu não veria um problema no meu caso se usasse, digamos, Git localmente, mas ainda usasse o git-svn para enviar minhas coisas para o SVN, para que o resto da equipe o tenha. Isso faz sentido?


Sim, isso faz sentido, mas você também deve considerar iluminando seus companheiros de equipe dos benefícios do Git mais de SVN
JD Isaacks

Concordo 100%, e acredite, eu tentaria, mas eles estão meio que ... definidos em seus caminhos. Vou colocar desta maneira .. eles escrevem o .NET 3.5 como se fosse o .NET 1.1; sem LINQ, sem novos recursos, nem mesmo genéricos. Temos alguns caras que estavam / estão realmente tentando nos fazer mudar do SVN para o VSS, melhorando o VSS (infelizmente um deles é o gerente de desenvolvimento, mas felizmente ainda não seguimos esse caminho ... ainda).
Wayne Molina

Você deve fazê-lo procurar por "VSS" aqui em programmers.stackexchange.com . Eu acho que isso assustá-lo ...
temor

0

Não é bom ter um desenvolvedor usando uma ferramenta de controle de origem diferente. Um objetivo do uso do controle de origem é melhorar o trabalho em equipe. E ele está violando essa regra e pode causar muitos problemas mais tarde, embora você trabalhe de maneira independente recentemente. Pergunte a ele por que ele prefere o VSS e diga as desvantagens de trabalhar dessa maneira.

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.