É incomum uma empresa pequena (15 desenvolvedores) não usar o controle de origem / versão gerenciado? [fechadas]

Não é realmente uma questão técnica, mas há várias outras perguntas aqui sobre controle de origem e melhores práticas.

A empresa em que trabalho (que permanecerá anônimo) usa um compartilhamento de rede para hospedar seu código-fonte e o código liberado. É de responsabilidade do desenvolvedor ou gerente mover manualmente o código-fonte para a pasta correta, dependendo do lançamento ou da versão e outras coisas. Temos várias planilhas espalhadas por onde gravamos nomes e versões de arquivos e o que mudou, e algumas equipes também colocam detalhes de diferentes versões na parte superior de cada arquivo. Cada equipe (2-3 equipes) parece fazer isso de maneira diferente dentro da empresa. Como você pode imaginar, é uma bagunça organizada - organizada, porque as "pessoas certas" sabem onde estão as coisas, mas uma bagunça porque é tudo diferente e depende de pessoas se lembrarem do que fazer a qualquer momento.

Eu tenho tentado pressionar por algum tipo de controle de fonte gerenciada por um tempo, mas não consigo obter suporte suficiente para ele dentro da empresa. Meus principais argumentos são:

• Atualmente estamos vulneráveis; a qualquer momento, alguém pode esquecer de executar uma das muitas ações de lançamento que precisamos executar, o que pode significar que versões inteiras não são armazenadas corretamente. Pode levar horas ou até dias para reunir uma versão novamente, se necessário
• Estamos desenvolvendo novos recursos, juntamente com correções de bugs, e geralmente precisamos atrasar o lançamento de um ou de outro, porque alguns trabalhos ainda não foram concluídos. Também precisamos forçar os clientes a usar versões que incluam novos recursos, mesmo que apenas desejem uma correção de bug, porque existe apenas uma versão em que estamos trabalhando.
• Estamos com problemas no Visual Studio porque vários desenvolvedores estão usando os mesmos projetos ao mesmo tempo (não os mesmos arquivos, mas ainda está causando problemas)
• Existem apenas 15 desenvolvedores, mas todos fazemos as coisas de maneira diferente; não seria melhor ter uma abordagem padrão para toda a empresa que todos temos que seguir?

Minhas perguntas são:

1. É normal que um grupo desse tamanho não tenha controle de origem?
2. Até agora, recebi apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?
3. Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

Estou pedindo principalmente para ter uma idéia do porquê de tanta resistência, por isso responda honestamente.

Vou dar a resposta para a pessoa que acredito ter adotado a abordagem mais equilibrada e respondeu às três perguntas.

desde já, obrigado

1. Pode não ser normal , mas como Treb diz , provavelmente não é tão incomum

2. Como outros já disseram, não há motivos válidos para não ter controle de origem em uma empresa do seu tamanho. Portanto, você precisa identificar e atacar os motivos inválidos :

   a) o principal é o status quo : "se não estiver quebrado, não conserte". Isso é difícil: você pode começar a apontar todas as coisas que não estão funcionando tão bem quanto deveriam (que podem rapidamente ser rotuladas como 'pessoas negativas') ou apenas esperar que algo exploda (o que pode nunca acontecer) ou você pode enfatizar todas as coisas que podem dar errado. Infelizmente, as pessoas encarregadas das pequenas empresas são relativamente impermeáveis à 'coisas que poderiam dar errado' até que eles realmente fazer dar errado ...

   b) ignorância / medo / incerteza : "nós realmente não entendemos o que é controle de fonte; não sabemos como usá-lo; não sabemos qual ferramenta escolher; isso vai prejudicar nosso estilo" . Essa é uma das razões pelas quais eu definitivamente não os enviava aqui! Pode ser uma tarefa bastante difícil para você, mas acho que, para maximizar suas chances, você precisa apresentar uma solução 'chave na mão', e não muitas variantes ou alternativas. Você precisa de uma idéia clara de: como deseja ajustar / transformar seu processo de trabalho para trabalhar com a ferramenta fornecida; como / se você planeja fazer a porta traseira do código existente; com que rapidez você pensa que pode 'treinar' usuários e colocá-los em funcionamento; como você pode gerenciar o período de transição (se houver); quanto é provável que "custe" (em horas, se não em dólares).

   c) pode haver outras razões (experiências ruins anteriores com o VSS, por exemplo, ou ter lido 'histórias de horror' sobre ferramentas supostamente complicadas), mas você terá que atacá-las individualmente quando as descobrir.

3. Existem amplas razões para o controle da fonte descritas nas outras respostas. Meu conselho seria escolher os 2 ou 3 principais que realmente poderiam fazer a diferença para sua empresa, aperfeiçoá-los e apresentá-los em uma reunião ao maior número possível de colegas. Tente provocar uma discussão: mesmo que não as convença imediatamente, você terá uma ideia do que podem ser os pontos negativos.

(Você leu / ouviu sobre a função Change ?)

Não é absolutamente normal que um grupo desse tamanho trabalhe sem controle de origem - o tamanho do maior grupo de programadores que podem trabalhar efetivamente sem controle de origem é menor ou igual a um. É absolutamente imperdoável trabalhar sem controle de versão para uma equipe profissional de qualquer tamanho, e talvez eu não esteja me sentindo criativo, mas não consigo encontrar nenhuma razão para que você queira renunciar.

O controle de versão é apenas mais uma ferramenta - uma ferramenta particularmente poderosa e que oferece enormes benefícios em relação ao seu custo mínimo. Ele oferece o poder de gerenciar todas as suas alterações de maneira organizada, com todos os tipos de outras coisas úteis, como ramificação, mesclagem automática, marcação e assim por diante. Se você precisar criar uma versão a partir de várias versões atrás, poderá verificar o código a partir desse momento e apenas compilar sem ter que passar por outros obstáculos.

Mais importante, se você precisar escrever uma correção de bug, poderá mesclá-la em uma atualização sem precisar fornecer os novos recursos em que está trabalhando - porque eles estão em outra ramificação e até o resto do desenvolvimento precisar preocupe, eles ainda não existem.

Você está enfrentando resistência porque está desafiando a cultura da empresa. Vai levar tempo para eles se ajustarem, não importa o que você diga. O melhor que você pode fazer é continuar pressionando e, se a empresa realmente não se mexer, encontre outro trabalho que seja mais adequado ao seu nível de desenvolvedor.

É normal que um grupo desse tamanho não tenha controle de origem?

Na minha experiência, não é a norma, mas não tão completamente incomum como sugerem outras respostas aqui. A maioria das pequenas empresas usa controle de origem, mas um número significativo, infelizmente, não.

Até agora, recebi apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?

Veja esta pergunta no SO para uma boa discussão. A resposta aceita diz:
"Não há boas razões para não usar o controle de versão. Nenhuma."

Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

O consenso entre todos os desenvolvedores e gerentes de projeto que conheci e, é claro, aqui em Programadores e SO é que o controle de origem é uma obrigação. É uma prática recomendada aceita . Se alguém decide ignorá-lo, ele precisa ter alguns argumentos muito fortes e convincentes sobre por que essa é a decisão certa para ele (ou seja, um pouco mais do que 'nunca precisamos dela, então por que precisamos disso no futuro'). Os argumentos que você apresentou até agora estão focados em questões específicas; talvez você deva tentar uma abordagem mais ampla ao longo das linhas de 'todo mundo faz isso; então, por que não fazemos isso também?

O controle de origem é bom para até uma única equipe de desenvolvedores. Qualquer sistema de controle de origem é basicamente um sistema de controle de versão que controla as alterações. Imagine um único desenvolvedor, que pode ter removido algum código e sente que o código agora é necessário. Ele pode recuperar o código antigo?

Basta procurar uma ferramenta que o ajude. O tamanho não importa em todos os lugares. A qualidade importa em todos os lugares.

Parece que você já está usando um sistema de controle de versão, mas não muito bom. As pessoas já parecem reconhecer a necessidade de controle de versão. Você só precisa apresentá-los ao próximo nível - controle de versão do software.

Se fosse eu, apresentaria o SCM como uma versão aprimorada do que eles já estão fazendo. Eu enfatizaria como o uso de uma boa ferramenta automatizará grande parte do trabalho que já está em andamento.

• Em vez de registrar as alterações em uma planilha, o sistema SCM controla não apenas o que mudou, mas quem mudou e por quê.

• Como bônus, você pode voltar a qualquer ponto da vida do código e ver o que realmente estava lá.

• Em vez de ter versões diferentes de código em pastas diferentes e precisar mover / mesclar itens entre pastas para portar uma alteração, você pode manter tudo no mesmo local e (mais importante), deixar a ferramenta fazer a mesclagem.

Como outros já disseram, eu esperaria alguma resistência, para prototipar o sistema usando-o nas coisas que estou fazendo.

(BTW, na verdade, coloquei meu currículo e outros documentos no SVN. Mais uma vez, desempenhei o papel de gerenciadores de configuração e integração várias vezes.)

Até agora, recebi apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?

• O produto que você está desenvolvendo é um sistema de controle de versão; os gerentes estão preocupados em impedir que os produtos existentes influenciem o design e a implementação do novo produto.

• Entre os fins de semana do BASE pulando e correndo com touros, os gerentes em busca de emoções gostam de dirigir para o trabalho, imaginando se tudo já deu errado.

• Evita aquisições hostis. Quem gostaria de adquirir uma equipe de desenvolvimento de software gerenciada dessa maneira?

Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

• Você já está controlando a versão, mas atualmente o faz da maneira menos eficiente, trabalhosa e propensa a erros que se possa imaginar. Usar um VCS economizará dinheiro, economizará tempo e melhorará a qualidade.

• Economiza espaço em disco. A maioria dos sistemas de controle de versão salva apenas os deltas entre os arquivos. Atualmente, você está salvando uma cópia inteira de cada versão de cada arquivo. (O backup de todas essas cópias deve levar muito tempo e espaço!)

• Vários desenvolvedores podem trabalhar no mesmo arquivo ao mesmo tempo e reconciliar as diferenças sem muita dificuldade. É claro que mesclar alterações é possível sem um VCS, mas é quase impossível acompanhar quem mudou o que, quando e por que nesse caso.

• Dá aos desenvolvedores liberdade para experimentar novas idéias, sabendo que podem recuperar qualquer versão a qualquer momento.

• Um processo melhor facilita a contratação e retenção de desenvolvedores talentosos.

É normal que um grupo desse tamanho não tenha controle de origem?

Não definitivamente NÃO. Quando eu comecei na minha empresa atual, havia uma pessoa para quem você deveria enviar seu código alterado e ele o mesclaria. Eu poderia convencer todos em poucos dias a usar o SVN.

Até agora, recebi apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?

Acho que o motivo pelo qual você só ouviu motivos vagos é porque não há motivos válidos para não usar o controle de versão.

Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

Sim, há muitas razões.

1. A ramificação oferece a possibilidade de desenvolver novas funcionalidades sem interferir em outros desenvolvimentos.
2. Cada confirmação fornece informações sobre o que exatamente foi alterado, quem fez essa alteração e quando essa alteração foi feita.
3. Você pode facilmente cometer correções de erros, implantá-las nos clientes e deixar de fora a nova funcionalidade inacabada.
4. Você pode manter versões diferentes, se os clientes tiverem medo de ir para uma versão mais recente.
5. Você pode trabalhar no mesmo projeto (até os mesmos arquivos de origem!) Com facilidade.
6. Você pode reverter facilmente um erro, preservando as alterações após esse erro cometido.

Algumas pessoas têm dificuldade em perceber o quão ruim é o status quo até verem algo melhor para si mesmas. O que você precisa é de uma boa demonstração . Mostre alguns exemplos reais de tarefas que poderiam melhorar. "Levei 4 horas para rastrear com nosso sistema atual, mas esse comando de controle de fonte me disse instantaneamente".

Não usar o controle de origem está pedindo problemas, mesmo para um desenvolvedor solo. O simples fato de você poder editar sem piedade, sem correr o risco de perder nada, compensa o esforço de aprendizado em semanas ou dias.

Dito isto, se você não conseguir convencer seus gerentes a introduzir o controle de origem, faça um favor a si mesmo e pelo menos use algo como git ou mercurial localmente - se as coisas explodirem devido à falta de controle de origem, pelo menos você não será o quem fez isso.

Minha empresa usa GIT para controle de versão. A empresa é um desenvolvedor, um CEO, um segurança, uma faxineira e um recepcionista. Todos eles sou eu. O controle de versão de origem é sempre obrigatório.

Eu trabalho em muitos projetos sozinho e ainda uso o controle de versão. O tamanho não importa. Sempre ajuda ter controle de versão.

Há uma razão para ser o número 1 no The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

Além disso, torna os números 2 e 3 da lista possíveis.

Estávamos em uma posição semelhante com uma equipe de 6 pessoas há alguns anos atrás. Um dos desenvolvedores deu o passo de instalar o SVN em um servidor de desenvolvimento onde a pasta compartilhada estava e apenas começou a usá-la.

Todos seguiram o exemplo e pouco tempo antes de implementarmos o CI ( CruiseControl ) e revolucionarmos nosso processo de criação e lançamento para incluir automação e verificações de qualidade.

WTF ?! Essa pode ser a pergunta mais ridícula que eu já vi. Você precisa encontrar um novo emprego. 15 desenvolvedores ?! Você acha que é uma equipe pequena? Isso é uma loucura. O gerente deve ser imediatamente rescindido. Honestamente, vou ter pesadelos depois de ler esta pergunta. Diga-nos o produto que você vende, para que todos saibamos que não o deve comprar! Não sei o que é mais assustador, esta pergunta ou resposta dizendo que isso não é incomum!

Não consigo imaginar como 15 desenvolvedores podem trabalhar sem nenhum controle de origem. No entanto, de:

(...) usa um compartilhamento de rede para hospedar seu código-fonte (...)

Suponho que você criou seu próprio controle de versão do pobre homem como o VSS (também baseado em pasta compartilhada). É arriscado e não eficiente.

Explique ao seu chefe como é ruim, invista em um treinamento de SVN ou GIT de 2 dias e comece a usar o sistema de controle de versão real enquanto você ainda tem o código em condições razoáveis.

Se eu não me comprometer várias vezes ao dia, ou pelo menos antes de sair para casa, sinto que ... algo está faltando, algo está errado.

Uma vez eu trabalhei em uma empresa com apenas 2 desenvolvedores (eu + administrador de cabelos compridos), em 1998. Mesmo assim, usamos svn. É tão conveniente.

Várias vezes na minha carreira perdi um dia de trabalho porque fiz algo como mv em vez de cp e depois rm -rf. Me fez chorar e passear pelas ruas da cidade em desespero.

Trabalhei em 5 empresas nos meus 13 anos de permanência no SE, participei de algumas conferências e nunca encontrei uma empresa que não estivesse usando controle de versão.

No entanto, minha empresa favorita de design de interiores, 20 funcionários, usa um quadro branco para gerenciamento de projetos + colaboração. Eles sabem que está errado, mas parecem não encontrar tempo para atualizar. De alguma forma, funciona embora. Não me pergunte como.

Seja um lider. Ser líder significa fazer o que é certo; resolução proativa de problemas. Liderança não está fazendo nada porque não há consenso suficiente. E um bom líder aprende a reconhecer situações em que se deve construir consenso e quando fazer. Esta é claramente uma situação real. A falta de controle de código explodirá em seus rostos mais cedo ou mais tarde.

Os líderes geralmente não estão em cargos oficiais de gerência. As pessoas seguirão líderes bons e decisivos, independentemente do título.

Se seus esforços decisivos são prejudicados, especialmente se for da gerência, é um sinal claro de que você pode sair dali. É um empecilho para o seu desenvolvimento profissional; Desenvolvedores competentes e gerenciamento incompetente não se misturam, e um incompetente com o poder vai ferrar você.

OK, os flashbacks estão me afetando. Assinando. Boa sorte.

1. Pegue um cronômetro,
   • Conte o tempo gasto na planilha apenas para sincronizar versões
   • Conte o tempo que você gasta consertando versões quebradas
   • conte o número de vezes que as pessoas gritam no corredor " Estou editando main.c !, apenas para garantir que ninguém mais esteja no momento!" .
   • conte o número de reclamações que você recebe dos clientes porque suas correções continham outras alterações
   • conte o atraso de lançamento apenas porque você não conseguiu sincronizar as versões
2. Faça um powerpoint com esses dados e compare com o funcionamento do vcs.
3. Mostrar gerenciamento

Este é apenas um acidente esperando para acontecer. Você não tem histórico de código e, de uma só vez, um de seus desenvolvedores pode acabar com meses de trabalho. Como uma empresa pequena, você não pode pagar esse tipo de revés.

Você também está muito exposto nessa unidade de compartilhamento. Mesmo com um bom backup, quanto tempo você pode se dar ao luxo de não trabalhar. 1 hora, 1 dia, 1 semana. Quanto tempo levaria para instalar um novo servidor, restaurar a partir do backup etc. Novamente, como uma pequena empresa, você provavelmente não possui hardware extra em modo de espera e pode não conseguir gastar dinheiro rapidamente para obter remessas aceleradas, etc.

Pense também no armazenamento externo. Uma inundação ou incêndio não é realmente tão incomum. O que aconteceria se houvesse um incêndio no prédio depois de horas. Quantos meses de trabalho seriam perdidos. Um repositório de código gerenciado como o github seria valioso para isso. Mesmo o uso de um servidor SVN simples em um serviço hospedado seria um avanço nessa área.

LordScree, estou em uma situação quase idêntica à sua, minha equipe imediata é de cerca de 15 desenvolvedores. Estou incrédulo (quase horrorizado) que o controle de fonte não seja usado. Minha resposta inicial a "deveríamos usar o controle de origem" foi "não temos tempo para implementar". Para mim, como usar roupas íntimas, o controle da fonte não é opcional. Depois de alguns meses, eu também tenho aprovação para implementar o TFS, escolhido pela organização porque é MS e vem com um teste de 90 dias. Resumindo, é muito difícil convencer uma organização da necessidade de controle de origem quando eles estão trabalhando juntos sem ela. Digo aos desenvolvedores que sempre que você se encontra fazendo backup de arquivos, especialmente com uma data no nome do arquivo ou diretório de backup, é um exemplo de quando você coloca algo no controle de origem. Eu não' Não tenho respostas brilhantes para você, mas acredito que isso é incomum. Estou travando a mesma batalha e vou mantê-lo informado sobre o progresso. E, esperançosamente, haverá algum progresso que eu possa procurar em outro lugar, porque não posso trabalhar no caos!

temos 3 membros da equipe de desenvolvimento e usamos o controle de origem. Nos meus projetos pessoais, tenho um desenvolvedor e uso o controle de origem. Não é apenas útil para o gerenciamento de equipes, é útil para poder fazer um trabalho experimental sem medo de que você esteja destruindo alguma coisa.

A maneira mais fácil de convencer o gerenciamento? Existe menos risco para o produto em geral e aumentará a produtividade do desenvolvedor a longo prazo. Ambos também são verdadeiros e apelam aos gerentes.

Não é de forma alguma um cenário normal e acho que você deve dar uma dura luta para obter essa configuração em sua empresa. Ele tem benefícios de longo alcance e não faz sentido perceber o mesmo quando você se aproxima do dia do juízo final e não é a situação que se enquadra Se não estiver quebrado, não conserte

Qualquer motivo para não implementá-lo pode ser apenas uma desculpa para um mau trabalho ou um erro que está por acontecer.

Apenas diga a eles o quão bom é encontrar o aplicativo em 1 de janeiro deste ano

como sobre hey esta funcionalidade foi adicionada março Acho que precisamos para expandir um pouco mais sobre isso.

Uau, esse bug 154256 foi corrigido neste commit.

posso ramificar o aplicativo e enviar a implantação sem problemas, pessoal, você pode continuar trabalhando.

Isso pode continuar ...

Eu uso o controle de versão para meus projetos individuais e para meus projetos de trabalho, onde temos mais de 30 a 40 pessoas trabalhando no mesmo código de uma só vez. O controle de versão tem suas vantagens organizacionais, mas a capacidade de reverter arquivos e ocultar alterações pode realmente aliviar a dor de cabeça do gerenciamento de código ... e, no final, esse é o melhor cenário para um programador, para que ele possa se concentrar apenas na codificação.

Os motivos para apoiar a não utilização do controle de versão são bastante limitados. Tudo o que consigo pensar é no aspecto técnico das coisas.

• Existe uma curva de aprendizado muito grande para converter o fluxo de trabalho de toda a equipe para incorporar um sistema de controle de versão que seja econômico.
• Seu gerente de projeto não considera que seria benéfico introduzir a sobrecarga no fluxo de trabalho de gerenciamento e manutenção de um repositório. (Principalmente um problema com sistemas de versão mais antigos)

Há muitos motivos para usar um sistema de controle de versão. No mínimo, pare de mudar as coisas. Trabalhe com patches. Os sistemas de controle de versão podem fazer exatamente o que você diz que faz.

• Você pode trabalhar na próxima versão ao mesmo tempo em que executa correções de bugs e liberá-las separadamente.
• Em vez de mover arquivos de um local para outro para trabalhar nele, você pode criar uma ramificação e mesclá-la no mestre após a conclusão.
• Cada desenvolvedor pode ter sua própria cópia do código-fonte para evitar que os problemas com o mesmo projeto sejam abertos em várias máquinas.
• Acidentes acontecem, se o código ficar gravemente quebrado, tudo o que você precisa fazer é reverter para o último número de revisão em funcionamento.
• O controle de versão funciona bem emparelhado com rastreadores de erros e sistemas de integração contínua.

Pessoalmente, como equipe de uma pessoa, use versionamento, rastreamento de bugs, integração contínua, revisão de código, verificação de consistência de código, testes de unidade, testes de selênio, análise de código-fonte, e pode haver mais que eu esteja esquecendo. Eu admito, há uma ligeira curva de aprendizado. Há também uma troca de tempo de administração adicional necessário para as etapas adicionais que você automatiza. Na minha experiência, o esforço economizado supera o tempo adicional de administração.

No meu primeiro trabalho sério em 1990, eu era o único desenvolvedor trabalhando no meu departamento e não sabia usar o controle de origem.

Logo depois eu aprendi, a partir de então nunca mais vi um projeto que não o tornasse uma das primeiras coisas que eles criaram.

Quase perdi todo o meu trabalho nesse trabalho porque excluí uma pasta no nível errado. Felizmente, eu havia trazido uma cópia para casa em um disquete de 10 cm na semana anterior e fui capaz de recriar as semanas de trabalho em alguns dias longos.

Acho que consideraria aceitável se fosse o primeiro projeto para todos da equipe e ninguém soubesse melhor, mas se apenas uma pessoa pudesse realmente explicar os benefícios e a equipe ainda não escutasse, eu categorizaria novamente meu a opinião do grupo de "ingênuo" a "perigosamente incompetente" (a resistência ao uso de uma ferramenta com benefícios tão amplamente demonstrados é quase criminosa - é como se sua equipe não confiasse em "Compiladores" e insistisse em fazer tudo em linguagem assembly) )

Eu tenho convencido muito isso ... em pequenas empresas de engenharia / eletrônica, onde elas fazem muito software / hardware incorporado.

Nesses locais, o SCM não faz parte da cultura de engenharia eletrônica. Eles geralmente têm um engenheiro por projeto, que só precisa fazer backup da versão mais recente.

Portanto, ramificar / mesclar e até compartilhar código é considerado irrelevante. Além disso, essas empresas provavelmente são ISO9000, portanto o processo, embora estranho, provavelmente está documentado.

De qualquer forma, eu / outros desenvolvedores começamos a usar o SCM pessoalmente.

Onde trabalho, temos o mesmo problema. Atualmente, estou tentando deslizar o controle de origem "sob o radar" para solucionar os mesmos problemas que você tem. Uso fósseis para os projetos que desenvolvo pessoalmente.

Recentemente, instalei um servidor fóssil na LAN da empresa, e agora é ainda mais conveniente. Espero que, ao demonstrar a utilidade em alguns projetos menores, minarei a resistência e nos afaste do status quo das pastas de rede.

Os maiores motivos que ouvi por não usar fósseis ou outros VCS são:

1. Muitos dos "programadores" são crianças de script e não entenderão como usá-lo
2. Aqueles que poderiam aprender pensam que é um incômodo usar
3. Essas pessoas são a velha guarda, confortáveis ​​com as pastas de rede, então todos devem estar
4. Ninguém tem tempo para configurá-lo corretamente ou aprender a usá-lo
5. Embora os recursos possam ser ótimos, nenhum deles é necessário

Como você pode ver, estou tentando contornar isso, demonstrando que é simples de usar, já configurado, fácil de aprender e que os recursos valem completamente a pena.

Por fim, mesmo que você não use o controle de origem, tudo está em uma árvore de rede. O Fossil pode fazer a versão de tudo na árvore inteira e você pode configurá-lo para ser executado sempre que ocorrer uma alteração no arquivo ou pelo menos a cada hora. Eu fiz isso em alguns de nossos projetos que "não precisavam de controle de origem" e isso acabou me permitindo reverter para uma boa versão quando algo desse errado.

Faça certo, e eles nem saberão que você fez. Então você pode ser o herói que restaura a versão quebrada e demonstra o quão útil é sua ferramenta.

Agora que ferramentas DVCS como Git e Mercurial estão disponíveis e são incrivelmente fáceis de configurar e usar, não há realmente desculpa para nem uma equipe de 1 (!) Usar o controle de origem. Não se trata do tamanho da equipe, é sobre ter um histórico comentado de suas alterações e a capacidade de suportar fluxos de trabalho, como corrigir problemas de produção enquanto trabalhava em uma nova versão e rastrear o estado do código-fonte para diferentes versões.

Se me oferecessem um emprego em uma equipe que chegasse a esse tamanho e nenhum dos desenvolvedores sugerisse o uso de um VCS, ou se a "gerência" os impedisse, eu recusaria. Não é apenas uma maneira aceitável de trabalhar nos dias de hoje.

Você deve obter um controle de versão do GIT imediatamente. Você pode usá-lo mesmo no Google Code Project Hosting. Quando os outros vêem você fazendo alterações em apenas um clique enquanto copiam manualmente as coisas, talvez eles mudem de idéia sobre isso.

Wow apenas wow. Embora eu não ache que seja a melhor maneira de lidar com o controle de código, não é totalmente incomum que eu trabalhei em uma empresa com 6 desenvolvedores e nenhum controle de origem foi usado, eles meio que tinham sua própria maneira interna de gerenciar arquivos, um gerente de lançamento e outros enfeites supervisionariam todas as mudanças. De fato, o mantra era que novas funcionalidades poderiam ser adicionadas aos projetos, desde que algum tipo de opção envolvesse a funcionalidade.

Por exemplo, estávamos trabalhando em uma rede social de alto nível escrita em PHP e o cliente queria que a funcionalidade pudesse se inscrever em um perfil de usuário. Basicamente, a funcionalidade foi agrupada em uma verificação como esta se (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {e execute o código}

O local em que trabalhei também nunca teve mais de um desenvolvedor trabalhando por vez em um arquivo específico, principalmente tudo era modular, portanto, nesse caso, não havia necessidade de controle de origem. No entanto, acredito que as vantagens do controle de origem superam as desvantagens de não tê-lo na maioria dos casos.

O fato de sua empresa estar recorrendo a planilhas documentando alterações de arquivos e o que foi alterado quando algo como Git ou Subversion pode lidar com isso é absolutamente ridículo.

Parece que você está convencido, mas alguém da organização não está capacitando você para fazê-lo. Como você pode ler nos outros comentários, você deve fazê-lo.

Você pode encontrar algumas informações aqui: http://www.internetcontact.be/scm/?page_id=358

O fator mais importante é que seus clientes são forçados à última ramificação 'instável' e se seus contratos com eles o tornam responsável pela implantação de versões instáveis, sua empresa está perdendo dinheiro. Você deve realmente se concentrar na estabilidade da versão aqui. Esse é o principal motivo do controle de origem e, como parece, sua principal falha. Os outros não serão aprimorados muito usando o controle de origem, pois você já possui sistemas alternativos.