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 .
-
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.
-
Culpa é extremamente difícil de fazer com a sua abordagem.
-
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. -
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.
-
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.
-
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.