Eu estou trabalhando em uma instituição governamental. A tecnologia que está sendo usada aqui e os métodos para o desenvolvimento de software são bastante antiquados.

Eles têm muito espaço de armazenamento, mas não há espaço apropriado para manter e manter aplicativos que são usados ​​para automatizar a maior parte do trabalho aqui.

A instituição não me permitiu usar software SCM como GIT ou SVN.

Qual seria a melhor abordagem para manter a qualidade do código e poder adicionar novos recursos aos aplicativos posteriormente?

Como me lembro das alterações que fiz no código sem quebrá-lo?

EDIT: esqueci de mencionar, eles têm unidades de rede para cada um dos computadores e, de alguma forma, essas unidades de rede fazem ou salvam backups em períodos. No entanto, se eu não criar meu próprio plano, permitindo salvar meu trabalho e poder adicionar novos recursos sem quebrar o código existente, não há grande vantagem sobre uma solução SCM.

EDIT: Como muitas pessoas sugeriram o Git portátil, tenho que adicionar mais informações. Tentei instalar o servidor Visual SVN, mas ele falhou porque não tenho privilégios de administrador para instalar. Também tentei baixar o shell Git normal, mas o firewall ou as configurações de rede não me permitiram acessar a página de download do Git. Até tentei enviar Git portátil para o meu e-mail, que é o Gmail. O Google detectou o arquivo exe no pacote e também não me permitiu baixar a versão portátil do Git no meu computador de trabalho. Outra coisa que devo mencionar, a política de rede aplicada aos computadores através da instituição não permite o uso de dispositivos de armazenamento USB. Você pode usar as portas USB para carregar o smartphone ou alimentar alguns dispositivos, como pequenos alto-falantes. Além disso, como algumas pessoas mencionaram, existem computadores nos quais nem a Internet é permitida.

Você pode replicar livremente a função que o controle de origem desempenha com três ferramentas simples:

• Software de backup (confirmações / check-ins)
• Pastas (Ramos)
• Realizando uma mesclagem de diretório entre dois diretórios usando uma ferramenta como o KDiff3 (Mesclando ramificações)

Basicamente, seu fluxo de trabalho se torna:

1. Crie uma nova pasta (nova ramificação)
2. Copie arquivos para a nova pasta (nova ramificação) de uma pasta existente (ramificação existente)
3. Faça um backup dessa pasta (termine de criar a nova ramificação)
4. Faça algum trabalho
5. Faça um backup da nova pasta (confirmação)
6. Fazer uma mesclagem de diretório de uma pasta para outra (mesclagem)
7. Faça outro backup na outra pasta (confirme a mesclagem)

Os sistemas de controle de fonte mais monolíticos, como SVN ou TFS, basicamente fazem isso por você nos bastidores.

Agora, a realidade é que é como uma empresa de ônibus dizendo a seus motoristas que eles não podem dirigir ônibus com bateria, forçando os motoristas a empurrar o ônibus colina abaixo e depois apertar a embreagem para ligar o ônibus ... isso é terrível e indica que a gerência atual não sabe nada sobre como administrar uma garagem de ônibus. Minhas condolencias.

Mas pelo menos você pode começar o ônibus.

Embora o consenso certamente não funcione para esta empresa , não acredito que realmente responda à sua pergunta.

Você realmente não pode substituir o SCM .

Você pode não precisar dos sinos e assobios habituais de um sistema completo. Por exemplo, a empresa pode recusar uma solicitação de servidor, mas permitir o uso de um SCM local. Eles podem não gostar do git, mas permitem a subversão (ou algum outro sistema de versão).

Obviamente, há uma pergunta: o que seus colegas estão usando ou algum trabalhador anterior? Se você é o primeiro desenvolvedor de software que eles têm, é hora de esforçar-se muito pelos recursos necessários.

No final, se sua empresa não respeitar seu papel e sua experiência e não permitir as ferramentas necessárias, você encontrará problemas ainda piores (e mais estressantes) do que a falta de controle de origem.

Basicamente, há um problema de gerenciamento (sua organização não entende o básico do processo de desenvolvimento de software , por exemplo, o modelo V ) condensando-se na aparente incapacidade de usar o fluxo de trabalho, a metodologia e as ferramentas mínimos da era atual. Isso é comum (leia sobre o princípio de Pedro ).

^{BTW, acho que o recente incidente ferroviário da SNCF em Paris no final de 2017 tem uma causa semelhante (total falta de cultura de software em alto nível de gerenciamento, daí o bloqueio de uma grande estação ferroviária de Paris por mais de um dia; é claro que há muita competência Equipes de TI da SNCF, mas elas não são consultadas sobre as principais decisões). Posso citar várias indústrias européias com total falta de cultura de software e tenho certeza de que encontrarei coisas semelhantes mesmo nos EUA.}

A questão principal é: você está trabalhando sozinho em sua base de código ou trabalha com colegas?

Se você estiver trabalhando sozinho, poderá usar o git localmente no seu computador e fazer backup do seu código (e provavelmente até do seu .gitrepositório) periodicamente (para esse espaço de armazenamento externo). Certifique-se de nunca perder mais de meio dia de trabalho (faça backup dos dados periodicamente e de maneira confiável).

^{(Suponho que você conheça pelo menos os dois gite svnque conheça a superioridade técnica git; se você não tem permissão para instalar alguma ferramenta como gitno seu computador de trabalho, precisa conversar seriamente com seu chefe sobre esse problema: você precisa a capacidade e a autorização para instalar ferramentas externas de código aberto (e isso é de sua responsabilidade de escolher, configurá-las e instalá-las com sabedoria, cuidado e sem vulnerabilidades conhecidas )}

Se você estiver trabalhando com vários colegas (acho que menos de uma dúzia deles), precisará convencer todos a usar um sistema de controle de versão e provavelmente precisará contar sobre isso ao seu chefe imediato (e comum). Ele poderia (provavelmente) decidir (ou simplesmente aceitar implicitamente) que alguma máquina (talvez até uma área de trabalho antiga, talvez até sua própria área de trabalho) seja usada como servidor git. Você absolutamente precisa configurar esse servidor para que o backup do repositório git seja feito pelo menos a cada hora; você não pode pagar (e precisa conversar com seu chefe) perder mais de uma hora de trabalho de sua equipe.

^{BTW, eu amo o Linux e eu recomendaria instalar o Linux na máquina que atua como gitservidor; instalar gite configurar backups periódicos (com algum crontabtrabalho) é muito fácil; observe que um gitservidor pode executar o Linux com clientes Windows usando-o. Eu sugiro que você mude sua máquina de desenvolvimento para Linux, se puder. É "mais barato" e muito mais amigável ao desenvolvedor}

Mas você precisa usar um SCM. Você pode fazer ao seu chefe uma pergunta diferente: sua equipe deve usar um SCM existente ou reinventar a roda e criar seu próprio SCM? Os chefes geralmente são contra a idéia de reinventar a roda. Se você tiver permissão para reinventar a roda, diga ao seu chefe que ele trabalha em período integral por pelo menos um ano (que provavelmente fará seu chefe chorar e aceite a maneira óbvia) e divirta-se criando seu próprio SCM. Nesse caso improvável, certifique-se de estudar os sistemas SCM existentes e peça para tornar seu sistema SCM uma ferramenta de software livre (a ser usada e aprimorada por outras equipes).

Pode ser necessário preparar (durante vários dias) uma argumentação precisa e específica para a necessidade de um SCM : primeiro para seus colegas, depois para seu chefe imediato. Certifique-se de sugerir também soluções concretas (como executar algum servidor git em algum desktop ou servidor "antigo" e fazer backup a cada hora em um crontabtrabalho)

Não instale nenhum software (de fora, nem de código aberto) em seu computador de trabalho sem permissão (na maioria dos países, especialmente para trabalhos confidenciais de TI para o Estado, a instalação de um software sem permissão é legalmente um crime, e você poderá perder seu trabalho ou ir para a prisão se você fizer isso ... tenha certeza de estar autorizado a fazê-lo; talvez cubra sua bunda pedindo uma permissão por escrito ou pelo menos por e-mail).

^{(você precisará solicitar caso a caso ou obter a confiança da sua organização para instalar qualquer software legal - principalmente código aberto ou software livre - no seu computador de trabalho).}

PS. Como tecnicamente construir, configurar, instalar e usargit (a partir do código fonte do software livre) - ou a maioria dos outros softwares VCS - em uma máquina (mesmo sem a permissão do administrador) é uma pergunta muito diferente (a ser feita em outro lugar). E é possível instalar e usar gitsem nenhuma permissão de administrador, desde que você tenha recursos suficientes (tempo, espaço em disco, algum compilador C, etc ...) para isso.

Tentei instalar o servidor Visual SVN, mas ele falhou porque não tenho privilégios de administrador para instalar.

Isso é solucionável por alguma configuração e compilação específica do seu gitou svndo código-fonte do software livregit ou do SubVersion - não apenas um pacote binário - (e também o código-fonte das dependências ); como tecnicamente fazer isso é uma pergunta diferente (mas essas questões técnicas devem ocorrer em outro lugar). Claro que você deve pedir permissão (do seu chefe) para compilar o código-fonte gitantes de fazê-lo. Ele lhe dirá, ou você discutirá com ele, sobre os detalhes práticos (se ele aceitar essa solução) sobre a transferência desse código-fonte de fora para o seu computador de trabalho.

A primeira coisa que eu faria é identificar especificamente o que a agência governamental (presumivelmente o departamento de TI) está objetando. Se eles têm espaço de armazenamento, mas não há maneira de hospedar VMs para servidores, o problema pode ser que o departamento de TI esteja dizendo não ao servidor SVN ou GIT e essa é uma grande distinção. Se o problema é o país de origem - ou seja, não confiamos em ferramentas criadas por entidades estrangeiras - esse é um problema diferente.

Você pode executar o GIT completamente dentro do sistema de arquivos, o que fiz em projetos infantis antes de estar pronto para fazer qualquer coisa com eles. O GIT também não requer privilégios administrativos para instalar.

Se você absolutamente não pode usar o Git por qualquer motivo, então você tem algumas opções disponíveis:

• Educar: ao não permitir o controle de versão, eles estão apresentando um risco significativo. Você precisa da capacidade de desistir de alterações que se revelam mais problemáticas. Você precisa da capacidade de economizar tempo e dinheiro do governo, e o SCM faz isso. Você precisa ser capaz de explicar claramente como. Você provavelmente também precisará fazer uma análise de alternativas para realmente esclarecer o ponto.
  • Uma alternativa seria hospedar o Git
  • Outro sistema de arquivos Git
  • Escolha pelo menos uma, mas não mais de duas ferramentas alternativas de SCM
  • e finalmente como é trabalhar sem controle de versão
• Desenvolvimento da era dos anos 70: há uma razão para isso patche que difffoi criada há muito tempo (anos 80). Eles foram as tecnologias que permitiram o controle de versão possível.

Como é o desenvolvimento da era dos anos 70? Não é bonito, mas é como começamos. Os aplicativos eram muito menores. Essencialmente, eles tinham algumas coisas em comum:

• Havia o conceito do padrão ouro . Este era o código-fonte principal que tinha os recursos completos.
• Havia uma equipe de gerenciamento de configuração (CM). A responsabilidade deles era obter mudanças desde o desenvolvimento até o padrão-ouro corretamente. É aqui que você precisa patche diffsubstitui a equipe.
• Você trabalhou a partir de uma cópia local do código fonte. Você termina um recurso em sua totalidade e o envia à equipe de CM para que ele se integre. Normalmente, há um documento de acompanhamento para que novos arquivos sejam criados e arquivos obsoletos, etc.
• Em seguida, você corrige quaisquer erros do processo de integração.
• Antes de se divertir com outro recurso ou correção de bug, você recebe uma nova cópia do padrão-ouro.

Essencialmente, é um processo propenso a erros com muito potencial para que as coisas dêem errado. A idéia de "ramificação" é fácil de implementar, mas um pesadelo para gerenciar. O principal problema é que, quando você tem muitas cópias do código-fonte, é difícil entender qual é a linha de base correta para a produção. Por uma questão de praticidade, você precisa se tornar único.

É isso que você precisa incluir na sua análise de alternativas.

Dadas as restrições mencionadas nos comentários (por exemplo: não é possível acessar a página de download do Git, a plataforma Windows e o uso do Visual Studio 2005), vejo duas opções, ambas as quais já usei antes em uma situação semelhante:

1. Use o Visual SourceSafe como Emerson sugere em um comentário. Eu trabalhei com uma equipe usando o VS 2005 há alguns anos, enquanto a maioria do restante da empresa estava usando o controle de versão padrão no Linux / Unix, e eles felizmente usavam o Visual SourceSafe para o seu CM. É bastante antiquado neste momento, mas melhor que nada.
2. Falando em melhor do que nada, eu já estive em uma situação semelhante. Se você não pode nem usar o VSS (talvez o plug-in não esteja instalado?), E como você diz que há muito espaço de armazenamento disponível, espero que você possa usá-lo. Eu implementei um protocolo manual de controle de versão baseado em arquivo. No final de cada dia de trabalho, eu copiava minha base de código em um novo diretório com data e carimbo. Se eu precisasse voltar ao trabalho anterior (ou reverter), procuraria nos diretórios datados anteriores para encontrar a alteração necessária. Como você tem o Visual Studio disponível, em algumas horas, provavelmente você pode usar o VS 2005 para escrever uma ferramenta simples para ajudá-lo a automatizar a criação de diretórios e a cópia de arquivos.

Eles têm toneladas de espaço de armazenamento

Você tem permissão para usá-lo na sua decisão?

Nesse caso, você pode criar um repositório remoto do sistema de arquivos melhor do que nada. A desvantagem é que empurrar fica lento enquanto o projeto está em crescimento, porque é gitnecessário fazer o download de todo o repositório para procurar as alterações ...

até agora, os computadores se comportam como usuários comuns, me proibindo de instalar software de terceiros.

gittambém vem como um aplicativo portátil, para que você possa instalá-lo no caminho $ HOME ou% USERPROFILE%.

Como conclusão: eu não deixaria que eles me proibissem de usar um SCM ¹ . Eu usaria "em particular". Afinal, ninguém pode dizer se o seu código foi desenvolvido com ou sem o check-in em algum lugar ...

¹ ) quando comecei a usar, githá alguns anos, meu cliente preferia um SCM diferente, que era bastante lento e não confiável (afinal, é um NOGO para um SCM (o;). Eu usei git"em privado" em cima do outro SCM com um controle remoto "baseado em arquivo" em um compartilhamento de rede e só fez check-in no SCM após o lançamento de uma nova versão do produto.

Seu ambiente

Antes de tudo, eu não seria tão pessimista como mostrado em muitos comentários e respostas. Sim, esta é a "idade da pedra", mas existem circunstâncias muito piores. Se o seu ambiente de trabalho geral (colegas, localização, remuneração, trabalho interessante de programação etc.) estiver bom e a seu gosto, por isso, mantenha-o. Em relação à TI, é o que é. Isso não acontece apenas em agências governamentais, mas também em bancos, seguros ou onde quer que haja um foco muito grande em segurança ou estruturas muito antigas.

Inserir um pendrive e executar algum arquivo .exe a partir daí seria motivo imediato de rescisão em outros lugares, por isso não sugeriria que você tentasse contornar qualquer coisa.

Tente git mais uma vez

Agora em sua escolha. Eu recomendaria fortemente o git em vez do svn para você. De qualquer maneira, se você estiver executando projetos individuais, o git é apenas um diretório local .gitdentro da raiz do aplicativo, nada mais.

Não solicite ao seu chefe / TI um "SCM", mas solicite a instalação específica gitem sua máquina para que você possa desenvolver mais rapidamente e com maior qualidade. Deixe claro para eles que você não deseja enviar seu código para outro lugar, que não precisa de um servidor executando em algum lugar e que não consumirá espaço significativo ou tempo de manutenção.

O Git aumentará a velocidade e a qualidade para você simplesmente porque você pode trabalhar com mais confiança (porque você pode desfazer as alterações que você fez) e permitirá que você trabalhe em várias ramificações ao mesmo tempo. Ou seja, se você estiver trabalhando em uma tarefa grande, e algo acontecer que precise de sua atenção imediata, basta mudar para um novo ramo, corrigir rapidamente isso e retornar à tarefa de longa duração.

Fazendo manualmente

Se isso não for possível, é claro que você pode fazer o controle manual da fonte. Crie "tags" manuais, copiando você mesmo seu código (talvez crie um novo diretório com a data / hora e uma breve descrição do que mudou). Mantenha um Changelog com listagens detalhadas não apenas de suas alterações, mas também dos arquivos que você alterou e talvez até mais detalhes.

Crie "ramificações" copiando seu trabalho novamente e, quando chegar a hora de voltar ao assunto, seja criativo usando algumas ferramentas arbitrárias "diff" ou "diff3" - não sei se você tem alguma disponível, será necessário descobrir.

Se tudo isso custar muito tempo, verifique com atenção se realmente vale a pena imitar um SCM. Se você achar que ele é vale a pena, em seguida, falar com o seu chefe de novo. Mostre a ele os benefícios do seu SCM manual (não apenas "Eu tenho uma cópia de todo o meu trabalho antigo", mas "quando o bug XYZ aconteceu, eu fui imediatamente capaz de encontrar o motivo, cinco versões atrás"). Em seguida, diga-lhes quanto mais rápido isso seria git.

Obviamente, se isso está deixando você louco, procurar emprego é sempre uma opção.

Eu acho que muitas pessoas aqui estão perdendo a "instituição do governo" desta questão. Algumas redes governamentais têm regulamentos muito rígidos sobre o software permitido a eles, e quebrar essas regras é uma ofensa passível de incêndio, talvez até criminal. Eu recomendaria o gerenciamento para ver se você pode obter algum movimento APROVADO para instalar o software. Eu não iria caubói e instalaria coisas sozinho. Se você estiver executando o Linux / UNIX, verifique se o RCS (comandos ci / co) ou SCCS (comando sccs) está instalado. Essas são ferramentas antigas do SCM que costumavam ser bastante padrão. Não é bonito, mas melhor do que estou prestes a escrever abaixo. :)

Como você tem "muito" espaço em disco, crie uma árvore de origem. Quais são os princípios básicos do SCM em pequena escala? Poder fazer o check-in das alterações, verificar o que foi alterado, marcar as coisas e voltar às versões antigas, se necessário. Um nível acima da árvore de origem, crie um Makefile ou scripts, dependendo do que você tem disponível, que faça o seguinte (estes são com sabor Linux / UNIX, os comandos do Windows seriam diferentes)

make checkin - cp -a data-tree-tree-source-tree (pelo menos até o minuto, se não o segundo, como source-tree-20171205115433)

make status - diff -R árvore de origem source-tree-date | menos (haveria um pouco de lógica aqui, o padrão é o backup mais recente ou fornece um argumento para diferenciar uma versão

tag make - ln -s source-tree-date release1.0 (crie um link para uma versão específica)

make revert - árvore-fonte rm -r && cp -a árvore-fonte-data-árvore-fonte

Venda para eles

Você deixou este comentário :

Eles têm uma unidade de rede que eu não sei, mas cria backups em períodos. Sim. Eu uso e guardo meus aplicativos lá.

Vá ao seu superior e diga algo nesse sentido:

Chefe, notei que temos um sistema em que colocamos aplicativos na unidade de rede e algum tipo de serviço faz backups e acompanha o histórico. Parece-me que estamos apenas implementando nosso próprio sistema de controle de origem fazendo isso. Provavelmente, poderíamos liberar muito espaço e tornar todo o sistema muito mais simples, mudando para um sistema de gerenciamento de controle de fonte dedicado, como SVN ou git. Obteríamos muitos benefícios: backups mais simples de versões históricas, ferramentas para entender quais alterações foram feitas nos arquivos ao longo do tempo (informações muito úteis para depuração), maneiras mais fáceis de desfazer erros e maneiras mais fáceis de combinar as mudanças de pessoas diferentes.

Já usei esses tipos de sistemas e eles são muito bons na tarefa que nossa configuração personalizada está executando. É muito mais difícil cometer erros do que é o nosso sistema atual. Eles também são tecnologias muito maduras e amplamente usadas; essas ferramentas são amplamente utilizadas há mais de 20 anos. Além disso, podemos usar o software mais popular sem pagar um centavo no licenciamento.

Eu ficaria feliz em ajudar a escolher um cliente e um servidor e configurá-los. Espero que levem [insert estimate here]horas para instalá-lo se eu conseguir uma máquina. Qualquer máquina faria, mesmo um desktop antigo prestes a ser aposentado, desde que possamos acessá-lo pela rede.

O resumo de alto nível aqui é que você precisa colocá-lo em termos que eles possam entender e provavelmente pensam que vale a pena:

• Liberando recursos (hardware e pessoas) para outros fins
• Menor risco (erro humano, tecnologia estável)
• Produtividade aumentada
• Pequeno custo para implementar

Seus superiores não são técnicos e não se importam com problemas técnicos. Mas se você puder enquadrar o problema em termos de dinheiro e coisas que custam dinheiro, seus ouvidos podem se animar um pouco.

Bem, depois de ler sua pergunta e muitos comentários, entendi que você tem as seguintes restrições / cenário:

• 1 pessoa por projeto;
• você simplesmente não pode usar ferramentas externas além do Visual Studio 2005 para seu projeto; você não pode usar o GIT ou qualquer outro SCM;
• enquanto trabalha localmente, não é possível deixar o projeto em um estado de falha, porque você tem backups automáticos de tempos em tempos e precisa fazê-lo funcionar o tempo todo;
• você precisa de algum histórico para acompanhar as alterações;

Se você não pode usar o Visual Source Safe (que possui plug-in para trabalhar com o VS 2005), poderá usar outra abordagem.

Com base nos itens acima, sugiro que você organize suas pastas de projeto, como abaixo:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Regras básicas a serem seguidas aqui:

• seu controle de código será executado dentro da pasta do projeto;
• você nunca trabalha no "tronco";
• você trabalha em "temp" , implementa testes de unidade , chama build.bat e, em seguida, save_on_trunk.bat ;
• IMPORTANTE: implemente testes de unidade executados em total isolamento; você precisa disso para garantir que o novo código não interrompa o tronco;
• como você tem backups automáticos, as chances de perder código serão menores; portanto, você só precisa fazer com que o código "tronco" fique em estado de funcionamento o tempo todo.

Você ficou sem soluções técnicas. Apenas soluções políticas permanecem.

1) Unionize os desenvolvedores. Se já existe um sindicato, desafie sua posição como não representando de maneira justa a classe de funcionário que é desenvolvedor. Se a formação de uma união de desenvolvedores falhar em obter o apoio de metade dos desenvolvedores, GO. Você é um mau ajuste.

2) Anúncio de jornal. Se o seu governo não garantir a liberdade de expressão como uma questão de direito reconhecida, você será demitido.

O Git para Windows possui uma versão "portátil" . Você pode copiar isso para o seu PC ou mantê-lo em um cartão de memória, sem precisar instalar nada. Se o problema for simplesmente instalação, isso seria uma solução alternativa.

Observe que, se eles são totalmente opostos ao SCM, você pode fazer perguntas específicas sobre ISO-9001, DO-178B ou outros padrões relevantes de desenvolvimento de software.

Basta executar o git em um diretório simples, sem nenhum servidor envolvido. Não importa que ninguém mais use o controle de versão, porque você pode controlar o diretório de versão. O Git foi projetado exatamente para esse cenário de introdução do SCM desonesto e funciona bem.

Você se tornará um herói quando a segunda pessoa começar a usá-lo, mesmo que tenha que esperar um dinossauro chutar o balde para que ele se espalhe. É incompetência gerenciar grandes bases de código sem o SCM agora. É como administrar um negócio sem auditar nada, na verdade.

Na verdade, existem três coisas que você gostaria de insistir como desenvolvedor profissional: revisões de código, histórico de versões e rastreamento de solicitações de alteração.

Você pode acompanhar as solicitações de alteração. Não é tão bom quanto com as ferramentas certas, mas você pode. A segunda parte são revisões de código. Para isso, você precisa da cópia anterior do seu código e de uma ferramenta diff. Quando você acha que uma alteração está pronta, revise-a comparando-a cuidadosamente com a versão anterior e substitua a versão anterior por uma nova.

Para controle de versão, se o seu local de trabalho não permitir uma solução decente, é uma caixa de DVDs graváveis ​​que você precisa. Toda vez que você tem uma versão que deseja manter para poder voltar, cria um novo DVD.

(Obviamente, tudo isso não é um conselho a ser seguido, a menos que você esteja em um local de trabalho muito ruim como o OP aparentemente).