Proteger los archivos de svn commit

Question

Oye, imagina una aplicación web simple con un log4j.properties que está bajo control de versión. No puedo agregarlo a svn:ignore porque es un archivo obligatorio. Si realizo cambios personalizados para el desarrollo y no quiero comprometerlos, tengo que tener cuidado con los commits accidentales. Para un archivo es fácil de manejar, con 3 o más archivos se vuelve espeluznante.

¿Hay alguna manera de deshabilitar temporalmente estos archivos de svn commit? Entonces, ¿es fácil comprometerse? Estoy trabajando con svn y subclipse.

Answer 1

La forma típica de manejar situaciones como esta es para hacer lo siguiente:

1. Haga una copia del archivo, bajo un nombre que indica que se trata de una plantilla
2. Commit la plantilla a su repositorio
3. Ignorar el archivo original

de esta manera, usted tendrá una nueva copia por ahí, y durante el despliegue se puede copiar el archivo de nuevo a partir de la plantilla para el archivo real.

De esta manera no corre el riesgo de realizar cambios incorrectos en este archivo, y al menos para el otro sistema de control de versiones, no se arriesga a que alguien revise el archivo y olvide el bloqueo.

En Subversion no hay forma de indicar que un archivo es solo un commit-first-time tipo de cosa, por lo que cuando lo agregaste a tu repositorio, le dijiste a Subversion que mantuviera un registro de los cambios en ese archivo. A menos que se asegure manualmente (o escriba una herramienta o cambie sus herramientas) para que nunca realice cambios en este archivo, Subversion no lo ayudará.

Answer 2

La forma en que hago esto es tener archivos llamados log4j.properties.server, por ejemplo, y luego he configurado mi script de implementación para copiar los archivos .server en lugar de los normales.

Answer 3

Mi solución a este problema fue crear un nuevo usuario (un poco virtual) en nuestro servidor svn y agregarlo a todos los proyectos, vamos a llamarlo Locker. Así que establecí un bloqueo, como usuario Locker, en los archivos de configuración que no deberían modificarse en la base de código.

Et voilà! Los archivos ya no se cometen por error. Sin embargo, si el sistema de producción necesita una actualización de los archivos de configuración, cualquier miembro del equipo puede forzar el bloqueo o los archivos pueden ser actualizados y bloqueados por aquellos que tengan conocimiento de las credenciales de Lockers.

Tal vez no sea una solución para todos, algunas regulaciones de la compañía pueden prohibir el uso de usuarios proxy.