Por que evitar bloqueio pessimista em um sistema de controle de versão?

Question

Com base em alguns lugares que eu li a respeito de controle de versão, parece que as pessoas pensam bloqueio pessimista em um sistema de controle de versão é uma coisa ruim. Por quê? Eu entendo que ele impede que um desenvolvedor de apresentar uma mudança enquanto outro tem o arquivo check-out, mas e daí? Se os seus arquivos de código são tão grandes que você sempre tem mais de uma pessoa a trabalhar sobre eles, ao mesmo tempo, eu proponho que você deve reorganizar seu código. Dividi-lo em unidades funcionais menores.

A integração de alterações de código simultâneos é um processo tedioso e propenso a erros, mesmo com as ferramentas de um bom sistema de controle de versão fornece para torná-lo mais fácil. Eu acho que deve ser evitado, se possível. Então, por que é bloqueio pessimista desanimado?

Answer 1

Depende de seu projeto e equipe em geral. bloqueio pessimista é bom, porque é fácil de compreender - um dev em um momento, e sem fusão necessário

No entanto, a única coisa ruim é sobre é exatamente isso - um dev de cada vez. Tenho a situação agora onde um colega passou no local, e antes de sair, ele verificado tudo para fora de modo que, se tivesse de corrigir todos os erros, ele poderia voltar e verificar todas as suas alterações em .... grande para ele , ruim para mim e para o resto da equipe de desenvolvimento de base.

Se você pode obter bloqueio em torno pessimista em sua equipe, em seguida, seu bom para usá-lo, realmente, os maiores razão as pessoas odiá-lo é porque a prática padrão, seu Visual SourceSafe. Se você não está confiante em fundir muitas mudanças, então você tem mais um motivo para usá-lo - se você já usou um SCM bloqueio otimista, e inclinou-se uma mesclagem, você sabe o quão difícil é recuperar <. / p>

Se você pode lidar com a fusão, em seguida, o bloqueio otimista é superior e eu recomendo-lo, mas você não tem que entregar o seu cartão geek em se você não quiser usá-lo.

Answer 2

1. Vá brincar com Source Safe e ter uma licença de desenvolvedor para uma semana de férias. Acrescente a isso os administradores VSS não estar por perto. Agora você tem uma correção a ser publicado, mas você não pode por causa do desenvolvedor
2. Se você tem vários recursos e / ou correções de bugs sendo trabalhado. Não importa quão pequeno o seu código é quebrado, você ainda terá disputa para um arquivo central.

Answer 3

1. Bob precisa editar FooBar.java
2. John tem o check-out para edição
3. Bob edita sua cópia local de qualquer maneira e salva-lo como FooBar.java.bak
4. Quando John verifica seu em, cheques bob fora
5. Bob cópias FooBar.java.bak sobre ele e verifica-lo em
6. John recebe reimplementar o recurso

Eu já vi isso acontecer uma e outra vez. Desenvolvedores fazer isso porque esse processo é chato:

1. Bob precisa editar FooBar.java
2. John tem o check-out para edição
3. Bob tem que esperar girando os polegares até que John é feito

sente bloqueio pessimista como amador, desculpe.

Answer 4

• Você não tem sempre a opção de arquivos quebrar
  • Arquivos de Configuração
  • Arquivos XML
• Mesmo relativamente pequenos arquivos ainda podem conter partes distintas que mais de um desenvolvedor precisa ter acesso a
  • Bibliotecas
  • Utilidades
• Mesclando ferramentas são muito mais espertos do que nunca
  • Os conflitos são bastante raras
• Reduz atrasos devido a desenvolvedores de ter arquivos "acidentalmente" check-out

Answer 5

Se um desenvolvedor não pode lidar com a fusão e fixação de conflitos, ele deve ser educado-re.

É comum que mesmo pequenos arquivos para obter conflitos, por exemplo, com JSPs uma pessoa (desenvolvedor web) pode estar mudando o código de layout, e alguém poderia mudar a API para o modelo que o JSP está usando.

Answer 6

Em relação ao caso com Bob e John, sistemas cooperativos como svn não impedem que este cenário não mais do que um sistema de bloqueio faz. Eu posso 'update' FooBar.java, que satisfaz svn que eu tenho a última edição, em seguida, apagar o arquivo localmente e substituí-lo com a minha própria cópia pessoal que fiz sem qualquer consideração para a versão de linha de base, e verificar que em, felizmente destruindo as alterações do outro rapaz. Nenhum sistema, travando ou não, impede que isso, então eu não vejo o ponto de até mesmo trazê-lo para o debate.

A verdadeira questão é decidir o seu saldo é entre

probabilidade de erros de mesclagem vs. inconveniente causado por pessoas arquivos de bloqueio

A noção de que quer um bloqueio ou sistema sem bloqueio é "superior" é um disparate.

Eu usei VSS, em seu modo de bloqueio completo padrão, com 6 desenvolvedores, e funcionou como um sonho. Ocasionalmente, alguém se esqueça de liberar um bloqueio e nós teria que caçá-los ou quebrar o bloqueio manualmente e mão-merge quando eles voltaram, mas este foi muito mínima. Eu vi svn parafuso até sua fusão automática mais de uma vez, de modo que eu realmente não confiar nele. Ele nem sempre um 'conflito' bandeira quando duas pessoas mudaram o mesmo arquivo de uma forma que não podem ser mescladas automaticamente juntos.
as pessoas Por outro lado, eu vi ficar impaciente com fechaduras de VSS, editar suas próprias cópias, e sloppily vê-los em cima do topo de código de outras pessoas, e eu já vi svn com folga me pegar quando eu acidentalmente pode tentar verificar algo em que foi alterada por outra pessoa desde a última vez xadrezes.

Meu ponto é, este não é um debate sensato ter. O sucesso de qualquer sistema vem para baixo a forma como você gerencia os pontos de conflito quando ocorrem, não se um sistema ou o outro é melhor.

Answer 7

bloqueio pessimista é (experiência pessoal) na forma de colaboração. Às vezes é facilmente substituído por uma boa comunicação equipe. Apenas dizendo "Ei, eu vou trabalhar neste alguns arquivos por um tempo".

Eu trabalhei em equipes de 2 a 6 pessoas, sem bloqueio e nós nunca tivemos um problema, além de algumas fusões habituais e necessárias.

Eu também trabalhei uma vez com bloqueio em um Visual SourceSafe hospedado projeto. Foi IMHO contra-produtivo.

Answer 8

Os desenvolvedores de software estão sempre otimistas - basta olhar para as suas skils estimativa

!

Na prática, encontramos conflitos são raros e os benefícios de não ter que se preocupar sobre o bloqueio superam a etapa de resolução de conflitos ocasionais.

Answer 9

Se os seus arquivos de código são tão grandes que você sempre tem mais de uma pessoa a trabalhar sobre eles, ao mesmo tempo

Se este for o caso, é hora de 'seres humanos' para assumir o comando e coordenar quaisquer alterações. No caso ideal, e se o seu gerenciamento de projetos é qualquer bom, você raramente vai bater um tempo em que você está tentando mudar um arquivo bloqueado porque alguém vai ter coisas coordenados para que isso não vai praticamente acontecer.

Em outras palavras, você vai saber 'Bob' está fazendo um grande conjunto de alterações em componentes X / Y / Z, se você tem uma correção de bug no X componente você vai saber falar com Bob antes de tentar enviar o seu alterações.

Como eu digo isso é ideal;)

Answer 10

bloqueio pessimista é uma boa idéia se sérios conflitos vão ser provável. Para a maioria de programação que você não vai ver quaisquer conflitos graves, então bloqueio pessimista é bastante inútil. Excepções a esta seria se você são:

• Trabalho em arquivos binários, onde você não pode realmente fundir - elementos de arte (modelos, texturas, etc.) são um exemplo bom
.
• Trabalho com usuários não-técnicos que não sabem como mesclar, e não quer aprender (principalmente artistas, mas alguns escritores técnicos irá lançar um ataque sobre isso também).
• Trabalho em arquivos muito grandes que não podem ser facilmente incorporadas ou quebrados em arquivos menores, devido ao alto grau de complexidade (nunca vi uma situação como essa primeira mão, mas eu tenho certeza que é possível).

Caso contrário ...