Estoy trabajando en una institución gubernamental. La tecnología que se usa aquí y los métodos para desarrollar software son bastante anticuados.

Tienen toneladas de espacio de almacenamiento, pero no hay espacio apropiado para guardar y mantener aplicaciones que se utilizan para automatizar la mayor parte del trabajo aquí.

La institución no me permitía usar software SCM como GIT o SVN.

¿Cuál sería el mejor enfoque para mantener la calidad del código y poder agregar nuevas características en las aplicaciones más adelante?

¿Cómo puedo recordar los cambios que he realizado en el código sin romperlo?

EDITAR: Olvidé mencionar que tienen unidades de red para cada una de las computadoras y de alguna manera estas unidades de red hacen o guardan copias de seguridad en períodos. Sin embargo, si no creo mi propio plan que permita guardar mi trabajo y pueda agregar nuevas funciones sin romper el código existente, no hay una gran ventaja sobre una solución SCM.

EDITAR: Dado que muchas personas sugirieron Git portátil, tengo que agregar más información. Intenté instalar el servidor Visual SVN, pero falló porque no tengo privilegios de administrador para instalar. También intenté descargar Git Shell normal, pero el firewall o la configuración de red no me permitieron acceder a la página de descarga de Git. Incluso lo intenté, enviando Git portátil a mi correo electrónico, que es Gmail. Google detectó el archivo exe en el paquete, y tampoco me permitió descargar la versión portátil de Git en mi computadora de trabajo. Otra cosa que debo mencionar es que la política de red aplicada a las computadoras a través de la institución no permite el uso de dispositivos de almacenamiento USB. Puede usar los puertos USB para cargar teléfonos inteligentes o alimentar algunos dispositivos como altavoces pequeños. Además, como algunas personas mencionaron, hay computadoras en las que ni siquiera Internet está permitido.

Puede replicar libremente el papel que juega el control de fuente con tres herramientas simples:

• Software de respaldo (commits / check-ins)
• Carpetas (ramas)
• Realizar una fusión de directorios entre dos directorios usando una herramienta como KDiff3 (Fusionar ramas)

Básicamente su flujo de trabajo se convierte en:

1. Crear una nueva carpeta (nueva rama)
2. Copie archivos a la nueva carpeta (nueva rama) desde una carpeta existente (rama existente)
3. Haga una copia de seguridad de esa carpeta (termine de crear la nueva rama)
4. Haz algo de trabajo
5. Haga una copia de seguridad de la nueva carpeta (commit)
6. Hacer una fusión de directorio de una carpeta a otra (fusionar)
7. Haga otra copia de seguridad en la otra carpeta (confirme la fusión)

Los sistemas de control de fuente más monolíticos, como SVN o TFS, básicamente lo hacen detrás de escena.

Ahora, la realidad es que esto es como una compañía de autobuses que les dice a sus conductores que no pueden conducir autobuses que tienen batería, lo que obliga a los conductores a empujar el autobús cuesta abajo y luego a apretar el embrague para arrancar el autobús ... esto es terrible e indica que la gerencia actual no sabe nada sobre el funcionamiento de un garaje de autobuses. Mis condolencias.

Pero al menos puedes arrancar el autobús.

Aunque el consenso ciertamente sería no trabajar para esta compañía , no creo que eso realmente responda a su pregunta.

Realmente no puedes reemplazar a SCM .

Es posible que no necesite las campanas y silbidos habituales de un sistema completo. Por ejemplo, la compañía puede rechazar una solicitud de un servidor, pero permitir el uso de un SCM local. Puede que no les guste git, pero permiten la subversión (o algún otro sistema de versiones).

Por supuesto, hay una pregunta: ¿qué están usando sus colegas o cualquier otro trabajador anterior? Si eres el primer desarrollador de software que tienen, entonces es tu momento de esforzarte mucho por los recursos que necesitas.

Al final, si su empresa no respeta su rol y experiencia y no le permite las herramientas que necesita, entonces se encontrará con problemas peores (y más estresantes) que la falta de control de la fuente.

Básicamente, hay un problema de administración (su organización no comprende los conceptos básicos del proceso de desarrollo de software , por ejemplo, el modelo V ) que se condensa en la incapacidad aparente de usar un flujo de trabajo, metodología y herramientas mínimas de la era actual. Esto es común (lea sobre el principio de Pedro ).

^{Por cierto, supongo que el reciente incidente ferroviario de SNCF en París a finales de 2017 tiene una causa similar (falta total de cultura de software a alto nivel de gestión, por lo tanto, bloqueo de una importante estación de tren de París durante más de un día; por supuesto, hay mucha competencia Equipos de TI en SNCF, pero no se les consulta sobre decisiones importantes). Puedo nombrar varias industrias europeas con una falta total de cultura de software y estoy seguro de poder encontrar cosas similares incluso en los Estados Unidos.}

El problema principal es: ¿está trabajando solo en su base de código o trabaja con colegas?

Si está trabajando solo, puede usar git localmente en su computadora y hacer una copia de seguridad de su código (y probablemente incluso su .gitrepositorio) periódicamente (en ese espacio de almacenamiento externo). Asegúrese de nunca perder más de medio día de trabajo (así que haga una copia de seguridad de sus datos de forma periódica y confiable).

^{(Supongo que conoce al menos ambos gity svnque conoce la superioridad técnica de git; si ni siquiera se le permite instalar alguna herramienta como giten su computadora de trabajo, necesita tener una conversación seria con su jefe sobre ese tema: necesita la capacidad y la autorización para instalar herramientas externas de código abierto (y eso va con su responsabilidad de elegirlas, configurarlas e instalarlas de manera inteligente y cuidadosa y sin vulnerabilidades conocidas )}

Si está trabajando con varios colegas (supongo que menos de una docena de ellos), debe convencerlos a todos para que usen un sistema de control de versiones, y probablemente deba informarle a su jefe inmediato (y común). Podría (probablemente) decidir (o simplemente aceptar implícitamente) que alguna máquina (tal vez incluso un escritorio antiguo, tal vez incluso su propio escritorio) se usa como servidor git. Es absolutamente necesario configurar ese servidor para que se realice una copia de seguridad del repositorio git al menos cada hora; no puede permitirse (y necesita hablar con su jefe sobre) perder más de una hora de trabajo de su equipo.

^{Por cierto, me encanta Linux, y recomendaría instalar Linux en la máquina que actúa como gitservidor; luego instalar gity configurar copias de seguridad periódicas (con algún crontabtrabajo) es muy fácil; Observe que un gitservidor podría ejecutar Linux con clientes de Windows usándolo. Incluso podría sugerirle que cambie su máquina de desarrollo a Linux si puede. Es "más barato" y mucho más amigable para el desarrollador}

Pero necesitas usar un SCM. Puede hacerle una pregunta diferente a su jefe: ¿su equipo debería usar un SCM existente o debería reinventar la rueda y hacer su propio SCM? Los jefes generalmente están en contra de la idea de reinventar la rueda. Si se le permite reinventar la rueda, dígale a su jefe que es un trabajo de tiempo completo durante al menos un año (eso probablemente hará llorar a su jefe, luego acepte la forma obvia) y diviértase haciendo su propio SCM. En ese caso improbable, asegúrese de estudiar los sistemas SCM existentes y solicite que su sistema SCM sea una herramienta de software gratuita (para que otros equipos la utilicen y la mejoren).

Es posible que deba preparar (durante varios días) una argumentación precisa y específica para la necesidad de un SCM : primero para sus colegas, luego para su jefe inmediato. Asegúrese de sugerir también soluciones concretas (como ejecutar algún servidor git en algún escritorio o algún servidor "antiguo" y hacer una copia de seguridad cada hora a través de un crontabtrabajo)

No instale ningún software (desde el exterior, incluso de código abierto) en su computadora de trabajo sin permiso (en la mayoría de los países, especialmente para el trabajo de TI sensible para el Estado, instalar un software sin permiso es legalmente un delito, y podría perder su trabajo o ir a la cárcel si haces eso ... así que asegúrate de estar autorizado para hacerlo; tal vez cúbrete el culo pidiendo un permiso por escrito o al menos por correo electrónico).

^{(o tendrá que preguntar caso por caso, o necesitará la confianza de su organización para poder instalar cualquier software legal -principalmente de código abierto o software libre- en su computadora de trabajo).}

PD. Cómo construir técnicamente, configurar, instalar y luego usargit (desde su código fuente de software libre) -o la mayoría de los otros VCS de software libre- en una máquina (incluso sin permiso de administrador) es una pregunta muy diferente (que debe hacerse en otro lugar). Y es posible instalarlo y luego usarlo gitsin ningún permiso de administrador, siempre que tenga suficientes recursos (tiempo, espacio en disco, algún compilador de C, etc.) para eso.

Intenté instalar el servidor Visual SVN, pero falló porque no tengo privilegios de administrador para instalar.

Esta es resoluble por alguna configuración específica y la compilación de su gito svndesde el software gratuito de código fuente de gito SubVersion -no sólo un paquete- binario (y también el código fuente de dependencias ); cómo hacer eso técnicamente es una pregunta diferente (pero esas preguntas técnicas deberían ir a otro lugar). Por supuesto, debe pedir permiso (a su jefe) para compilar el código fuente de gitantes de hacerlo. Él le informará, o usted discutirá con él, sobre los detalles prácticos (si acepta tal solución) con respecto a la transferencia de ese código fuente desde el exterior a su computadora de trabajo.

Lo primero que haría es identificar específicamente a qué se opone la agencia gubernamental (presumiblemente el departamento de TI). Si tienen espacio de almacenamiento, pero no hay forma de alojar máquinas virtuales para servidores, entonces el problema puede ser que el departamento de TI está diciendo que no al servidor SVN o GIT y eso es una gran distinción. Si el problema es el país de origen, es decir, no confiamos en las herramientas creadas por entidades extranjeras, ese es un problema diferente.

Puede ejecutar GIT completamente dentro del sistema de archivos, lo que he hecho en proyectos infantiles antes de que esté listo para hacer algo con ellos. GIT tampoco requiere privilegios administrativos para instalar.

Si no puede usar Git por alguna razón, entonces tiene un par de opciones disponibles:

• Educar: al no permitir el control de versiones, están introduciendo un riesgo significativo. Necesita la capacidad de retirarse de los cambios que resultan ser más problemáticos. Necesita la capacidad de ahorrar dinero y tiempo al gobierno, y SCM lo hace. Necesita poder explicar claramente cómo. Probablemente también necesite hacer un análisis de alternativas para realmente llevar el punto a casa.
  • Una alternativa sería Git alojado
  • Otro sistema de archivos Git
  • Elija al menos una, pero no más de dos herramientas SCM alternativas más
  • y finalmente cómo es trabajar sin control de versiones
• Ir desarrollo era 70s: Hay una razón por la cual patchy diffse hizo hace tanto tiempo (80). Eran las tecnologías habilitadoras que hicieron posible el control de versiones.

¿Cómo es el desarrollo de la era de los 70? No es bonito, pero así es como empezamos. Las aplicaciones fueron mucho más pequeñas. Esencialmente tenían algunas cosas en común:

• Existía el concepto del patrón oro . Este fue el código fuente maestro que tenía características completas.
• Había un equipo de gestión de configuración (CM). Su responsabilidad era obtener los cambios del desarrollo en el estándar de oro correctamente. Aquí es donde lo necesita patchy diffpara sustituir al equipo.
• Trabajó desde una copia local del código fuente. Termina una característica en su totalidad y la envía al equipo de CM para que la integren. Por lo general, hay un documento adjunto para que se creen nuevos archivos y se eliminen archivos obsoletos, etc.
• Luego corrige los errores del proceso de integración.
• Antes de que pueda entretener otra función o corrección de errores, obtendrá una nueva copia del estándar de oro.

Esencialmente, es un proceso propenso a errores con un gran potencial para que las cosas salgan mal. La idea de "ramificación" es fácil de implementar, pero una pesadilla para administrar. El problema principal es que cuando tienes demasiadas copias del código fuente es difícil entender cuál es la línea base correcta para la producción. Por razones de practicidad, debe convertirse en un solo subproceso.

Esto es lo que necesita incluir en su análisis de alternativas.

Dadas las restricciones que menciona en los comentarios (por ejemplo: no puedo acceder a la página de descarga de Git, la plataforma de Windows y usar Visual Studio 2005), puedo ver 2 opciones, las cuales he usado antes en una situación similar:

1. Use Visual SourceSafe como Emerson sugiere en un comentario. Trabajé con un equipo usando VS 2005 hace algunos años, mientras que la mayoría del resto de la compañía estaba usando el control de versión estándar en Linux / Unix, y felizmente usaron Visual SourceSafe para su CM. Es bastante anticuado en este momento, pero mejor que nada.
2. Hablando de algo mejor que nada, he estado en una situación similar. Si ni siquiera puede usar VSS (¿tal vez el complemento no está instalado?), Y dado que dice que hay mucho espacio de almacenamiento disponible, es de esperar que pueda usarlo. Implementé un protocolo manual de control de versiones basado en archivos. Al final de cada día de trabajo, copiaría mi código base a un nuevo directorio con fecha. Si tuviera que referirme al trabajo anterior (o retroceder), miraría los directorios con fechas anteriores para encontrar el cambio que necesitaba. Dado que tiene Visual Studio disponible, en un par de horas, probablemente podría usar VS 2005 para escribir una herramienta simple que lo ayude a automatizar la creación de directorios y la copia de archivos.

Tienen toneladas de espacio de almacenamiento.

¿Se le permite usarlo a su decisión?

Si es así, podría crear un repositorio remoto del sistema de archivos que sea mejor que nada. La desventaja es que empujar se vuelve lento mientras el proyecto está creciendo porque gitnecesita descargar todo el repositorio para buscar los cambios ...

Hasta ahora, las computadoras se comportan como usuarios normales, lo que me impide instalar software de terceros.

gittambién viene como una aplicación portátil para que pueda instalarla en su ruta $ HOME o% USERPROFILE%.

Como conclusión: no dejaría que me prohibieran usar un SCM ¹ . Lo usaría "en privado". Después de todo, nadie puede decir si su código ha sido desarrollado con o sin haber sido revisado en algún lugar ...

¹ ) cuando comencé a usarlo hace gitalgunos años, mi cliente prefería un SCM diferente que era bastante lento y poco confiable (que es una especie de NOGO para un SCM después de todo (o;). Usé git"en privado" encima del otro SCM con un control remoto "basado en archivos" en un recurso compartido de red y solo se registró en su SCM después de que se lanzó una nueva versión del producto.

Su entorno

En primer lugar, no sería tan pesimista como se muestra en muchos comentarios y respuestas. Sí, esta es la "edad de piedra", pero hay circunstancias mucho peores. Si su entorno de trabajo general (colegas, ubicación, pago, trabajo de programación interesante, etc.) está bien y es de su gusto, entonces manténgalo. En cuanto a TI, es lo que es. Esto no solo ocurre en las agencias gubernamentales, sino también en la banca, los seguros o en cualquier lugar donde haya un gran enfoque en la seguridad o en estructuras muy antiguas.

Insertar una memoria USB y ejecutar algunos archivos .exe desde allí sería causa inmediata de terminación en otros lugares, por lo que no te sugiero que intentes evitar algo.

Prueba git una vez más

Ahora en su elección. Recomiendo encarecidamente git en lugar de svn para ti. Si de todos modos está haciendo proyectos de una persona, entonces git es solo un directorio local .gitdentro de la raíz de su aplicación, nada más.

No le pida a su jefe / TI un "SCM", pídales específicamente que lo instalen giten su máquina para que pueda desarrollarse más rápido y con mayor calidad. Que sea claro para ellos que usted no desea empujar su código a otro lugar, que usted no necesita un servidor que ejecuta alguna parte, y que va a no utilizar el espacio o el mantenimiento de tiempo significativo.

Git aumentará la velocidad y la calidad para usted simplemente porque puede trabajar con más confianza (porque puede deshacer los cambios que hizo) y le permite trabajar en varias ramas al mismo tiempo. Es decir, si está trabajando en una tarea grande y entra algo que necesita su atención inmediata, puede cambiar a una nueva rama, solucionarla rápidamente y luego volver a la tarea de larga duración.

Hacerlo manualmente

Si simplemente no es posible, entonces, por supuesto, puede hacer un control de fuente manual. Cree "etiquetas" manuales copiando su código usted mismo (tal vez cree un nuevo directorio con la fecha / hora y una breve descripción de lo que cambió). Mantenga un registro de cambios con listados detallados no solo de sus cambios, sino también de los archivos que cambió, y tal vez incluso de más detalles.

Cree "ramas" copiando nuevamente su trabajo, y cuando sea el momento de volver a fusionarse, sea creativo utilizando algunas herramientas arbitrarias "diff" o "diff3". No sé si tiene alguna disponible, tendrá que descubrir.

Si todo esto le cuesta mucho tiempo, analice detenidamente si realmente vale la pena emular un SCM. Si usted encuentra que es digno de él, y luego hablar con su jefe de nuevo. Muéstrele los beneficios de su SCM manual (no solo "Tengo una copia de todo mi trabajo anterior" sino "cuando ocurrió el error XYZ pude encontrar la razón de inmediato, hace 5 lanzamientos"). Luego dígales cuánto más rápido sería con esto git.

Obviamente, si esto te está volviendo loco, buscar trabajo siempre es una opción.

Creo que a mucha gente aquí le falta la "institución gubernamental" de esta pregunta. Algunas redes gubernamentales tienen regulaciones muy estrictas sobre el software permitido, y romper esas reglas es un delito que se puede disparar, tal vez incluso criminal. Lo empujaría a través de la administración para ver si puede obtener un movimiento APROBADO al instalar el software. No iba a ser vaquero e instalar cosas yo mismo. Si está ejecutando Linux / UNIX, vea si RCS (comandos ci / co) o SCCS (comando sccs) están instalados. Estas son herramientas SCM antiguas que solían ser bastante estándar. No es bonito, pero es mejor que lo que voy a escribir a continuación. :)

Como tiene "mucho" espacio en disco, cree un árbol de origen. ¿Cuáles son los principios básicos de SCM a pequeña escala? Poder revisar los cambios, ver qué ha cambiado, etiquetar cosas y volver a las versiones anteriores si es necesario. Un nivel por encima del árbol de origen, cree un Makefile o scripts, dependiendo de lo que tenga disponible, que haga lo siguiente (estos tienen sabor a Linux / UNIX, los comandos de Windows serían diferentes)

make checkin - cp -a source-tree source-tree-date (al menos hasta el minuto, si no el segundo, como source-tree-20171205115433)

hacer estado - diff -R árbol-fuente fuente-árbol-fecha | menos (habría un poco de lógica aquí, por defecto a la copia de seguridad más reciente o dar un argumento para diferenciar en contra de una versión

make tag - ln -s source-tree-date release1.0 (crea un enlace a una versión en particular)

make revert - rm -r árbol-fuente && cp -a árbol-fuente-fecha árbol-fuente

Véndelo a ellos

Dejaste este comentario :

Tienen una unidad de red que no sé cómo, pero crea copias de seguridad en períodos. Si. Lo uso y guardo mis aplicaciones allí.

Ve a tu superior y dile algo en este sentido:

Jefe, noté que tenemos un sistema donde colocamos aplicaciones en la unidad de red y algún tipo de servicio hace copias de seguridad y realiza un seguimiento de la historia. Me parece que solo estamos implementando nuestro propio sistema de control de fuente al hacer esto. Probablemente podríamos liberar mucho espacio y simplificar todo el sistema al cambiar a un sistema de gestión de control de fuente dedicado, como SVN o git. Obtendríamos muchos beneficios: copias de seguridad más simples de versiones históricas, herramientas para comprender qué cambios se hicieron en los archivos con el tiempo (información muy útil para la depuración), formas más fáciles de deshacer errores y formas más fáciles de combinar los cambios de diferentes personas.

He usado este tipo de sistemas antes, y son muy buenos en la tarea que realiza nuestra configuración personalizada. Es mucho más difícil cometer errores con ellos que con nuestro sistema actual. También son tecnologías muy maduras y ampliamente utilizadas; Estas herramientas han sido ampliamente utilizadas por más de 20 años. Y además de eso, podemos usar el software más popular sin pagar un centavo en licencias.

Estaré encantado de ayudar a elegir un cliente y un servidor y configurarlos. Supongo que solo tomaría [insert estimate here]horas instalarlo si puedo obtener una máquina. Cualquier máquina funcionaría, incluso un viejo escritorio a punto de ser retirado, siempre que podamos acceder a él a través de la red.

El resumen de alto nivel aquí es que debe ponerlo en términos que puedan entender y que piensen que vale la pena:

• Liberación de recursos (hardware y personas) para otros fines.
• Menor riesgo (error humano, tecnología estable)
• Productividad incrementada
• Pequeño costo de implementación

Sus superiores no son personas técnicas y no les importan los problemas técnicos. Pero si puede enmarcar el problema en términos de dinero y cosas que cuestan dinero, sus oídos podrían animarse un poco.

Bueno, después de leer su pregunta y muchos comentarios, entendí que tiene las siguientes restricciones / escenario:

• 1 persona por proyecto;
• simplemente no puede usar herramientas externas que no sean Visual Studio 2005 para su proyecto; no puedes usar GIT o cualquier otro SCM;
• mientras trabaja localmente, no puede dejar el proyecto en un estado roto, porque tiene copias de seguridad automáticas de vez en cuando y necesita que funcione todo el tiempo;
• necesita un poco de historia para rastrear los cambios;

Si no puede usar Visual Source Safe (que tiene un complemento para trabajar con VS 2005), entonces podría usar otro enfoque.

En base a los elementos anteriores, le sugiero que organice las carpetas de su proyecto como a continuación:

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)

Reglas básicas a seguir aquí:

• su control de código se realizará dentro de la carpeta del proyecto;
• nunca trabajas en "baúl";
• trabaja en "temp" , implementa pruebas unitarias , llama a build.bat y luego save_on_trunk.bat ;
• IMPORTANTE: implemente pruebas unitarias que se ejecuten en aislamiento total; necesita esto para garantizar que el nuevo código no rompa el tronco;
• Como tiene copias de seguridad automáticas, las posibilidades de perder el código serán menores; por lo tanto, solo necesita hacer que el código de "troncal" esté en funcionamiento todo el tiempo.

Te has quedado sin soluciones técnicas. Solo quedan soluciones políticas.

1) Sindicalizar a los desarrolladores. Si ya existe un sindicato, desafíe su posición como no representando justamente a la clase de empleado que es desarrollador. Si formar una unión de desarrolladores no logra obtener el apoyo de la mitad de los desarrolladores, GO. Te queda mal.

2) Anuncio en el periódico. Si su gobierno no garantiza la libertad de expresión como una cuestión de derecho reconocida, esto lo despedirá.

Git para Windows tiene una versión "portátil" . Puede copiar esto a su PC o guardarlo en una tarjeta de memoria, sin necesidad de instalar nada. Si el problema es simplemente la instalación, esto sería una solución alternativa.

Tenga en cuenta que si son totalmente opuestos a SCM, es posible que desee hacer preguntas puntuales sobre ISO-9001, DO-178B u otros estándares de desarrollo de software relevantes.

Simplemente ejecute git sobre un directorio simple, sin ningún servidor involucrado en absoluto. No importa en absoluto que nadie más use el control de versiones, porque puede controlar la versión de su directorio. Git fue diseñado para este escenario de introducción de SCM falso, y funciona bien.

Te convertirás en un héroe cuando la segunda persona comience a usarlo, incluso si tienes que esperar a que un dinosaurio patee el cubo para que se extienda. Es incompetente administrar grandes bases de código sin SCM ahora. Es como manejar un negocio sin auditar nada, en realidad.

En realidad, hay tres cosas diferentes en las que querría insistir como desarrollador profesional: revisiones de código, historial de versiones y seguimiento de solicitudes de cambio.

Usted mismo puede rastrear las solicitudes de cambio. No es tan bueno como con las herramientas adecuadas, pero puedes hacerlo. La segunda parte son las revisiones de código. Para eso, necesita la copia anterior de su código y una herramienta de diferencias. Cuando cree que un cambio está listo, lo revisa usted mismo comparándolo cuidadosamente con la versión anterior, luego reemplaza la versión anterior por una nueva.

Para el control de versiones, si su lugar de trabajo no permite ninguna solución decente, necesita una caja de DVD grabables. Cada vez que tiene una versión que desea conservar para poder volver, crea un nuevo DVD.

(Obviamente, todo esto no es un consejo que se debe tomar a menos que se encuentre en un lugar de trabajo realmente malo, como aparentemente lo está el OP).