Usando SVN mal - Mercurial é a resposta?

No trabalho, usamos SVN, mas apenas no nome. Nós não ramificamos ou mesclamos. Mantemos duas cópias do repositório, uma servindo como o ramo "tag" que é copiado quando fazemos uma implantação e mantida para correções de bugs e os recursos imediatos do tipo "isso precisa ser ativado o mais rápido possível". Temos que lembrar de copiar as alterações feitas em uma cópia para a outra cópia (o "tronco"). Temos uma dúzia de projetos dentro de uma única pasta no repositório, em vez de dividi-los. Em resumo, a única coisa em que usamos o SVN é poder confirmar. Tudo o resto é feito manualmente.

Eu tenho avaliado o Mercurial; Eu usei o Git no passado (eu sou o único na equipe que usou um DVCS) e estou adquirindo o Mercurial rapidamente. Estou debatendo a introdução do Mercurial para o restante da equipe como uma "maneira melhor" de fazer as coisas, porque a ramificação é rápida, a fusão é muito mais fácil, e podemos comprometer as coisas localmente com o conteúdo do nosso coração e apenas empurrá-las para o centro ramifique quando estiverem prontos. Obteríamos todos os benefícios do SVN (e não estamos obtendo muitos benefícios no momento, já que ninguém realmente entende o SVN), além de novos recursos, não precisamos ter toneladas de arquivos não versionados flutuando por isso, se precisarmos reverter Estamos ferrados. O fluxo de trabalho parece um pouco mais simples - basta lembrar que "Commit" é local e "Push" é como o commit do SVN,

Essa é uma boa abordagem a ser adotada? Lembre-se de que a equipe é muito flexível e aceita tudo o que melhora nossa qualidade de trabalho e facilita a maneira como fazemos as coisas - o CIO até me perguntou quando mencionei como não estávamos usando o SVN em seu potencial "É existe algo melhor que podemos usar? " então ele também está a bordo.

Sim.

Se você substituir "SVN" por "Perforce" no seu OP, terá praticamente a situação em que me encontrei quando iniciei meu trabalho atual, mesmo na cópia de alteração manual. Dois anos depois, estamos no Mercurial e todos concordam que foi uma grande mudança.

Temos a capacidade de ramificar e mesclar por caso de suporte , o que é incrivelmente útil para o controle de qualidade, e a capacidade de criar qualquer número de ramificações e repositórios descartáveis ​​sempre que acharmos melhor, que podemos construir e verificar em nosso servidor de CI e implantar para um ambiente de teste na nuvem e verifique a funcionalidade. Isso foi de grande benefício em termos de tranquilidade, pois, quando fazemos uma implantação em tempo real, temos quase 100% de certeza de que funcionará (problemas de ambiente sem DB / banco de dados, que obviamente estão fora do escopo do VCS).

Basicamente, o que ganhamos ao mudar para o mercurial é o espaço para respirar. Não precisamos mais nos preocupar com o custo de uma filial, ou as terríveis sessões de mesclagem que inevitavelmente costumavam seguir, tudo é muito mais fácil. Também usamos muito o FogBugz, de modo que o vínculo com o Kiln (seu mercurial hospedado) é realmente útil.

O comentário sobre o site hginit também é destacado , como um esboço para um fluxo de trabalho de controle de versão que realmente funciona (supondo que você o ajuste para o fluxo de trabalho de QA específico da sua empresa).

A única falha possível nos controles de versão em movimento é que você precisará de alguém que seja realmente uma força motriz por trás da mudança, que esteja feliz em ler sobre o assunto e realmente usar as ferramentas da melhor forma possível, o que você parece querer Faz.

Não concordo com os comentários sobre o tamanho da equipe e a distribuição da equipe relacionados ao uso do DCVS. Realmente, é sobre a distribuição de CODE. Se você tiver vários ciclos de desenvolvimento em paralelo, seja caso de suporte em um sistema legado ou vários recursos ou até mesmo novos sistemas (que, pelo que você faz), você se beneficiará do uso de um DVCS.

Provavelmente, uma ferramenta diferente não resolverá seu problema. Eu diria que você deveria ler este artigo, achei mais útil:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Eu acho que o ponto principal do artigo está resumido aqui, mas por favor, leia-o:

No final: não realmente sobre as ferramentas

Em todo o tempo que passei trabalhando e integrando diferentes sistemas de controle de origem, cheguei a uma conclusão: não é a ferramenta, é como você a usa. Essa é uma afirmação terrivelmente hackeada, mas parece especialmente verdadeira aqui. Quando usado para gerenciar adequadamente as alterações no código-fonte - rotulagem de compilações, ramificação por exceção etc. - até o sistema de controle de origem mais fraco (* tosse * SourceSafe * tosse *) superará em muito a configuração do Mercurial com um monte de confirmações aleatórias e empurra.

Não. A tecnologia raramente resolve esse tipo de problema.

O Mercurial é mais complexo que o Subversion (sim, ramificar e mesclar é melhor e talvez mais fácil, mas o modelo do Subversion é muito mais simples que o Mercurial). Se você estiver usando o Subversion de maneira tão desafiadora, poderá acabar usando o Mercurial:

• a) Adequadamente ou melhor
• b) Inadequadamente, mas melhor que o uso atual do Subversion
• c) Tão inadequadamente quanto agora
• d) Pior do que agora

c) ed) soam como os resultados mais prováveis. Anote por que você acha que vai acabar em a) ou b).

Não posso falar sobre como as equipes grandes funcionam, mas para equipes pequenas muitos desses grandes problemas de SVN não são realmente problemas de SVN ... São problemas de desenvolvimento. Se você não está seguindo os padrões modernos de desenvolvimento (o mais importante é a integração contínua), o controle de versão se transforma na bagunça exata que você está descrevendo ... Antes de passar para um novo sistema, certifique-se de realizar uma verdadeira análise da causa raiz do seu problema ...

Não. As ferramentas não substituem a metodologia.

Se você não usa o Subversion como SCM , também não pode usar o Mercurial (e isso provavelmente acontecerá)

O SVN pode fazer o que você precisa e não há necessidade de mudar de cavalo no meio do fluxo para obter um pagamento duvidoso.

Faça o que fizer, você terá que superar um problema de confiança. Alguém precisa convencer a todos a mudar seu fluxo de trabalho. Isso não é fácil, mesmo nas melhores circunstâncias, mesmo se você tiver lógica e fatos ao seu lado. É uma das coisas mais difíceis de fazer em uma organização. Se você estragá-lo ou for difícil, você perde a confiança e será muito difícil recuperar essa confiança.

Sei que há algumas coisas que as pessoas tentaram com sucesso. Talvez um deles funcione para sua equipe:

1. Traga um "treinador" para fornecer uma série de workshops para a equipe. Provavelmente terá que ser uma pessoa externa (ironicamente, muitas vezes é mais fácil para muitas equipes confiar em alguém de fora do que confiar em alguém da equipe). Tem que ser alguém que saiba tudo de dentro para fora e que possa efetivamente ensinar essas habilidades a pessoas de todos os níveis de entendimento e elaborar um plano pragmático para implantar o novo VCS (*) no fluxo de trabalho da equipe.

2. Inicie um projeto "skunk-works" para testar e validar o novo VCS em um pequeno projeto paralelo. Escolha alguns desenvolvedores "alfa" que estão dispostos a experimentar coisas novas e não se importam em fazer várias experiências malsucedidas. Quando o skunk-works conseguir demonstrar melhorias irrefutáveis ​​da CONCRETE no fluxo de trabalho, você poderá tentar lançá-lo para o restante da equipe e terá alguns evangelistas para ajudá-lo.

(*) por "novo VCS" não quero dizer necessariamente mercurial ou git, também pode ser SVN (feito corretamente).