tortoise - svn manual

¿Cómo versionar los archivos de configuración de control pragmáticamente?

Question

Supongamos que tenemos un archivo de configuración con contraseñas confidenciales. Me gustaría controlar la versión de todo el proyecto, incluido el archivo de configuración también, pero no quiero compartir mis contraseñas.
Eso podría ser bueno, si este archivo de configuración:

database_password=secret
foo=bar

se convierte

database_password=*
foo=bar

y los otros usuarios de los vcs también podrían configurar la contraseña por sí mismos. Ignorar el archivo no es un buen enfoque, los desarrolladores deben tener en cuenta si el archivo de configuración cambia.

Ejemplo:

Versión local:

database_password=own_secret
foo=bar

archivo de configuración en vcs:

database_password=*
foo=bar

Entonces, de repente, el archivo de configuración cambia:

database_password=*
foo=bar
baz=foo

Y la versión local se convertiría para cada desarrollador:

database_password=own_secret
foo=bar
baz=foo

Esta es mi solución. ¿Cómo podría lograr este comportamiento? ¿Cómo almacena sus archivos de configuración? ¿Hay alguna manera de hacerlo, o debería piratear algo?

Answer 1

¿Qué pasa con un gancho precompromiso para borrar los campos confidenciales? Esto supone que te sientes cómodo enviando el archivo a través de la red en primer lugar, por supuesto.

Actualización para el otro lado del problema:
Para manejar las actualizaciones, o bien desea forzar una fusión manual de los archivos confidenciales, o modificar el proceso de compilación local para sobrescribir las líneas sensibles con los contenidos de un archivo local / privado / ignorado.

Answer 2

¿Tiene un archivo por separado con SÓLO los secretos, que no está bajo control de versión?

O, idealmente, elimine las contraseñas utilizando por completo openssh, o similar, y realice la autenticación de clave pública / privada para cada usuario.

Answer 3

Cree un archivo de reemplazos locales que contenga la información específica del usuario como variables de PHP.

Por ejemplo, cree un archivo llamado local_overrides.php que contenga lo siguiente:

$local_password = ''qUzaEAFK13uK2KHy'';

Luego, en el archivo que incluye su contraseña de DB, haga algo como esto

$overrides = ''local_overrides.php'';
if (file_exists($overrides)) {
#include_once($overrides);
$db_password = $local_password;
} else {
// perform appropriate action: set default? echo error message? log error?
$db_password = ''l1m1t3d!''
}

El control de origen nunca debe ver el archivo de anulaciones locales.

Answer 4

En lugar de controlar la versión del archivo de configuración real, puede poner una plantilla o archivo predeterminado en el control de la versión y un script que solicite información y credencial de DB para generar el archivo de configuración real, que se excluirá de (es decir, se ignorará) control de versiones. Al finalizar la compra, los desarrolladores podrían ejecutar este script para obtener un entorno de trabajo. Este script también se puede invocar como parte de cualquier proceso de instalación que use su aplicación.

También vea mi respuesta a una pregunta similar.

Answer 5

En mis proyectos, utilizo un directorio que contiene este tipo de archivos, pero no está cargado en el servidor, por lo que mi archivo de configuración db está en ese directorio y está configurado para el servidor donde se ubica el proyecto. Si alguien cambia el archivo de configuración, cambiará el archivo de configuración del servidor y cualquiera que actualice la revisión verá los cambios en ese archivo y tendrá que cambiar manualmente su configuración local.

No veo una manera de hacerlo en lugar de eso. Si encuentra un enfoque diferente, por favor comparta.

Answer 6

Estoy acostumbrado a hacer un archivo txt con la estructura del archivo de configuración. Y después de eso, haré una copia y cambiaré la extensión y dejaré que mi sistema de control de versiones ignore este (s) archivo (s).

Entonces, cuando realice cambios en el archivo de configuración, simplemente actualice la versión de texto. Esa es la única opción que puedo pensar que también es lógica (en mi opinión)

Answer 7

Mi respuesta preferida a esto ya se mencionó aquí: compruebe un archivo ficticio, genere el archivo "real" copiando el archivo ficticio en tiempo de ejecución e ignore el archivo "real" en su VCS.

Ya respondí una pregunta similar, con un ejemplo completo de cómo hacer esto en Visual Studio:
cómo ignorar archivos en horno / mercurial usando tortuga hg "que son parte del repositorio"

Answer 8

No estoy seguro de cómo se implementa su configuración, pero tener superposiciones jerárquicas es cómo manejaría esto.

Usted tiene una configuración principal que contiene la configuración común más el nombre de usuario / contraseña ficticios (o los omite por completo). Cada desarrollador crea un override.config local (o lo que sea) con su nombre de usuario / contraseña específico. La configuración principal pasa a estar bajo control de fuente, las modificaciones locales del desarrollador (o máquina) no lo hacen.

He hecho esto en .NET pero no en PHP, así que no sé qué tan fácil sea esto, me temo.

Answer 9

Tenía algo similar a esto, aunque no sé si funcionaría para usted. Tenía un directorio que contenía archivos que contenían contraseñas. Este directorio no estaba controlado por la versión. Los archivos fueron nombrados después de las aplicaciones que los usaron y en los archivos de configuración, obtuve el archivo de contraseña apropiado en el momento en que era necesario. Esto exigiría que su analizador de configuración pueda manejar el origen.