Em que ponto o controle de versão é necessário? [duplicado]

Conforme você descreve, você já tem algum tipo de controle de versão, embora atualmente haja alguns problemas em relação a um controle de versão típico:

Uma confirmação intencional no controle de versão indica que o desenvolvedor acredita firmemente que o estado atual do sistema seria criado com êxito.

(Há exceções, conforme sugerido por O comentário de Jacobm001 .Na verdade, várias abordagens são possíveis, e algumas equipes preferem não tentar fazer com que cada comprometimento seja construído. Uma abordagem é ter builds noturnos, dado que durante o dia, o sistema pode receber vários commits que não são compilados.)

Como você não tem commits, seu sistema geralmente resulta em um estado que não é construído. Isso impede que você configure Integração Contínua .

A propósito, um sistema de controle de versão distribuído tem um benefício: é possível fazer commits locais o quanto for necessário enquanto traz o sistema para um estado onde ele não pode construir, e então fazer um commit público quando o sistema for capaz de construir .

1. O controle de versão permite que você aplique algumas regras no commit . Por exemplo, para arquivos Python, o PEP 8 pode ser executado, evitando a confirmação se os arquivos confirmados não forem compatíveis.

2. Culpa é extremamente difícil de fazer com a sua abordagem.

3. Explorando quais alterações foram feitas quando e por quem é difícil também. O controle de versões logs , a lista de arquivos alterados e a diff é uma excelente maneira de encontrar exatamente o que foi feito.

4. Qualquer mesclagem seria uma dor (ou talvez os desenvolvedores nem percebessem que seus colegas estavam modificando os arquivos antes de salvar as alterações). Você afirmou que:

   It's rare that the same project is worked on by two programmers

   Raro não significa nunca, então as mesclagens ocorrerão mais cedo ou mais tarde.

5. Um backup a cada quinze minutos significa que os desenvolvedores podem perder até quinze minutos de trabalho . Isso é sempre problemático: é difícil lembrar exatamente quais mudanças foram feitas enquanto isso.

6. Com o controle de origem, você pode ter mensagens de confirmação significativas. Com backups, tudo o que você sabe é que foram x minutos desde o último backup.

Um controle de versão real garante que você sempre possa reverter para o commit anterior; Esta é uma grande vantagem. Reverter um backup usando seu sistema seria um pouco mais difícil do que fazer uma reversão de um clique , o que você pode fazer na maioria dos sistemas de controle de versão. Além disso, no seu sistema Ramificação é impossível.

Existe uma maneira melhor de fazer o controle de versão, e você certamente deve pensar em mudar a maneira como o faz atualmente. Especialmente desde que, como Eric Lippert menciona , seu sistema atual é provavelmente muito mais doloroso de manter do que qualquer sistema comum de controle de versão. Ter um repositório Git ou Mercurial em uma unidade de rede é muito fácil, por exemplo.

Observação: Mesmo se você mudar para um sistema de controle de versão comum, ainda deverá ter um backup diário / semanal dos repositórios. Se você estiver usando um sistema distribuído, é menos importante, pois a cópia de trabalho de cada desenvolvedor também é um backup.

Apenas minha opinião pessoal: o controle de versão é útil para qualquer coisa que leve mais de meio dia ou envolve muitas tentativas e erros - ou ambos, é claro. Se envolver duas ou mais pessoas que não estejam usando o mesmo teclado e monitor o tempo todo, é essencial.

O custo de usar um sistema de versionamento formal, além da curva de aprendizado inicial, é insignificante. Inicializando um repo? Dois segundos. Adicionando arquivos? Um segundo. Ser capaz de voltar ao que tentei esta manhã e discutir o que descartei com o meu colega? Vale horas ou dias, facilmente.

O controle de versão sempre foi necessário, mesmo antes de você hackear seu "mas, nós fazemos backup com muita frequência!" kludge.

O controle de versão permite publicar essas alterações nos arquivos que pertencem a uma função lógica como uma unidade. Se você precisar revisar "o que era necessário para a classificação sem distinção entre maiúsculas e minúsculas nessa máscara?", Ela informará todas as alterações relevantes e suprimirá as irrelevantes.

O bom controle de versão registra nomes de arquivos, metadados e a proveniência de cada linha de código individual.

O controle de versão permite marcar todas as alterações com o motivo pelo qual você as criou.

Controle de versão não significa permitir que mais de uma pessoa trabalhe em conjunto. Trata-se de garantir o registro histórico da sua base de código. Seguro com o conhecimento de que você não pode perder nada, ou até mesmo esquecer quando você fez isso e como, você está livre para refatorar, inventar e criar sem medo. E você não sabe o que é destemido antes de experimentá-lo.

Há um grande valor no uso do controle de versão, mesmo como um desenvolvedor individual, e pode ser um pouco mais simples do que o sistema baseado em cópia de backup / arquivo que você tem agora.

• Agora, você tem a capacidade de acessar a versão mais antiga do código, mas como você encontra a versão desejada?
• Apenas a capacidade de fazer uma diferença entre as revisões será muito valiosa. A integração com ferramentas de desenvolvimento é outro benefício que você não está recebendo de suas ferramentas atuais.
• Outro benefício substancial é a capacidade de ramificar e experimentar novos recursos ou designs sem ter que se preocupar em quebrar nada.
• Como foi mencionado em outras respostas, a capacidade de comprometer intencionalmente o código que você deseja compartilhar com os outros é substancialmente diferente de salvar todas as versões do código em intervalos de 15 minutos. Você está, sem dúvida, salvando várias versões de código não funcionais que você ou outras pessoas precisarão mais tarde para encontrar a versão boa anterior que você realmente precisa.

É bastante simples instalar e executar um sistema de controle de versão particular em um ambiente tão direto quanto este. Portanto, o investimento necessário não é muito alto. Como mencionei, o sistema baseado em backup que você tem agora parece ser desnecessariamente complexo e potencialmente frágil. Você deve se beneficiar dos anos de investimento que a comunidade fez na construção de ferramentas como SVN, Git ou Mercurial para resolver exatamente o problema de manter várias versões do software e fornecer uma boa quantidade de recursos adicionais que é diretamente útil para desenvolvedores.

Ao configurar e usar o controle de versão formal, você desenvolverá um valioso conjunto de habilidades que o ajudará em toda a sua carreira. Quase todo ambiente de desenvolvimento de software profissional usa um sistema de controle de versão. Conhecer os detalhes de como configurar e usar um repositório ajudará você de novo.

Eu não estou familiarizado com o Mercurial, mas pelo que entendi, é um sistema de controle de revisão completo. Se você já tem alguma familiaridade com ele, pode valer a pena começar a experimentá-lo como um VCS.

Em um ambiente profissional em que há código escrito , você deve sempre ter o controle de origem .

Há sempre o perigo de um candidato a uma entrevista perguntar o que você usa para o controle de versão e recusar a posição por causa da falta de um sistema de controle de versão razoável.

Além disso, se você for capaz de contratar um profissional, ele também poderá ter muito mais dificuldade para entender e usar seu ambiente de versão atual.

Como outras pessoas já disseram, "agora" é sempre um bom momento para começar a usar o controle de versão. Há tantos benefícios em usar um bom sistema de controle de versão que é quase um acéfalo.

Você mencionou que usa o Mercurial. Como outros vcs distribuídos, você sempre pode inicializar seu próprio repositório (privado) e trabalhar lá. Por que não tentar isso? Se começar a funcionar para você, pode funcionar para sua equipe. DVCS é tudo sobre construção a partir do zero.

O controle de versão é realmente uma das partes mais importantes de uma equipe de desenvolvimento funcional. Além do ponto de vista de que seu código sempre é submetido a backup, você está exposto a recursos como mensagens de confirmação que o ajudam a entender exatamente o que a pessoa antes de você (ou você mesmo) fez com um determinado arquivo. Você também pode diferenciar arquivos com versões anteriores e criar tags para lançamentos específicos. As tags são um grande benefício, pois basicamente você pode criar um instantâneo da versão x.x.x do código-fonte do seu aplicativo. Isso faz com que rastrear bugs antigos seja muito mais fácil.

Comece a ler em diferentes plataformas e veja o que melhor atende às suas necessidades. Usamos o SVN porque havia ferramentas integradas em nosso IDE para alavancar o SVN. Ironicamente, nem sequer usamos essas ferramentas agora, apenas usamos o Tortoise SVN para fazer check-in e check-out do código.

Para responder à sua pergunta, o controle de versão é necessário a partir do momento em que você escreve sua primeira linha de código.