Versionado de documentos: por qué "final_v2_definitivo.docx" es un problema
Cuando el nombre del archivo es lo único que dice cuál versión es la vigente, el sistema de versionado eres tú, a mano — y falla justo cuando más importa.
final.docx, final_v2.docx, final_v2_definitivo.docx, final_v2_definitivo_AHORA_SI.docx. Cada nombre nuevo es un intento de resolver el mismo problema: comunicar cuál es la versión vigente sin ningún sistema real detrás que lo garantice. Funciona mientras una sola persona edita el documento y se acuerda del orden. Deja de funcionar apenas hay más de una persona, o pasa más de una semana.
Cómo falla el versionado manual
Hay dos formas de que falle, y las dos son comunes. La primera es la sobreescritura silenciosa: alguien abre el archivo, lo edita, y guarda sobre el mismo nombre — la versión anterior desaparece sin dejar rastro, ni siquiera la posibilidad de comparar qué cambió. La segunda es la proliferación de copias: cada edición genera un archivo nuevo con un nombre ligeramente distinto, y con el tiempo nadie puede afirmar con certeza cuál de los seis archivos parecidos es el que realmente se usó la última vez.
Ambos fallos comparten la misma causa raíz: el nombre del archivo está haciendo el trabajo que debería hacer un sistema — identificar de forma inequívoca cuál es la versión vigente y qué pasó con las anteriores.
Qué necesita capturar una versión de verdad
Una versión útil no es solo "el archivo nuevo" — es un registro de quién la subió, cuándo, y a qué documento pertenece. Esa última parte es la que el versionado manual no puede resolver: sin una identidad estable que conecte todas las versiones de un mismo documento entre sí, cada archivo nuevo es, en el mejor de los casos, una suposición de a qué pertenece.
Con un Record, esa identidad ya existe de entrada: todas las versiones de un contrato específico están atadas al mismo registro, sin importar cuántas veces se haya subido una revisión ni cómo se llame cada archivo.
Cuándo es una versión nueva, y cuándo es un documento distinto
No todo lo que se sube es una nueva versión de algo existente. Un contrato revisado con el mismo cliente, corrigiendo una cláusula, es una versión nueva del mismo Record. Un contrato distinto con otro cliente, aunque use la misma plantilla, es un Record nuevo — no una versión de un contrato que no tiene nada que ver.
Confundir estos dos casos rompe tanto la búsqueda como la auditoría: agrupar documentos que no están relacionados bajo un mismo historial hace que ese historial deje de significar algo, y separar revisiones de un mismo documento en registros distintos hace imposible ver la evolución real de ese documento a lo largo del tiempo.
El costo real de perder el historial
El problema no aparece el día a día — aparece cuando alguien necesita reconstruir qué pasó: demostrar cuál versión de un contrato firmó realmente un cliente, investigar quién cambió un monto y cuándo, o simplemente confirmar que la versión que se está usando hoy es la más reciente y no una copia que quedó dando vueltas por correo. En ese momento, la diferencia entre tener el historial completo y no tenerlo es la diferencia entre resolver la pregunta en minutos o no poder responderla con certeza.
Preguntas frecuentes
¿Cuántas versiones se pueden guardar de un mismo documento?
No hay un límite artificial — cada carga nueva simplemente se suma al historial del mismo Record. Lo que importa no es cuántas versiones existan, sino que cada una quede identificada con quién la subió y cuándo, para que el historial siga siendo útil en vez de solo una lista larga sin contexto.
¿Se puede volver a una versión anterior si la nueva tiene un error?
La versión anterior nunca se pierde ni se sobrescribe — siempre queda disponible para consultar y descargar. En la práctica, "volver atrás" significa subir esa versión anterior de nuevo como la más reciente, dejando también un registro de que eso fue lo que pasó, en vez de borrar la versión con el error como si nunca hubiera existido.