¿Cómo maneja los archivos individuales del desarrollador bajo el control de la versión?

Question

Algunos archivos en nuestro repositorio son individuales para cada desarrollador. Por ejemplo, algunos desarrolladores utilizan una base de datos local, que se configura en un archivo de propiedades en el proyecto. Entonces cada desarrollador tiene configuraciones diferentes. Cuando un desarrollador se compromete, siempre debe tener cuidado de no comprometer sus archivos configurados individualmente.

¿Cómo manejas esto?

Answer 1

Nuestros archivos de propiedades se encuentran en un directorio de "propiedades". Cada desarrollador tiene sus propios archivos "username.properties" que pueden anular las propiedades en los archivos específicos del entorno, como "dev.properties", o "test.properties". Esto aprovecha las propiedades inmutables de ANT (incluidas las propiedades personales primero, ENTONCES del entorno).

Answer 2

Use SVN: Ignore (o su equivalente) para asegurarse de que no estén registrados en la rama de su troncal.

Answer 3

Bien, pero por ejemplo, un archivo db-config debe mantenerse bajo control de versión y no debe ignorarse.

Answer 4

Construimos o aplicación utilizando nuestros archivos de generación Ant Ant y tiene una referencia a un nombre de archivo de la siguiente manera:.

$ {} env.COMPUTERNAME - propiedades

Todas las propiedades en este archivo se anula las propiedades en el archivo de construcción principal, si existen. De modo que los desarrolladores pueden crear un archivo de anulación, llamado así por el nombre de su máquina, para anular cualquiera de las propiedades que les gusten, por ejemplo, el nombre de la base de datos o la URL jdbc. Este archivo se puede verificar en el control de versión

Answer 5

No los mantenga bajo control de versiones, y utilice la herramienta de ignorar de su herramienta para evitar que se registren accidentalmente. En su lugar, actualice una secuencia de comandos que los genera, que puede usar datos controlados por versión y locales, sin versión -controlada de datos. Esto los mantiene actualizados, a la vez que cuenta con las modificaciones locales adecuadas, sin peligro de que estas modificaciones vuelvan al repositorio.

EDITAR: algunos formatos de archivo tienen la capacidad de utilizar opcionalmente sobrescrituras locales. Estos pueden registrarse, pero en general, muchos no son lo suficientemente inteligentes como para hacer esto. De ahí esta solución.

Answer 6

Deberían absolutamente mantenerse bajo control de versiones. Puede usar una variable de entorno en el entorno del usuario para detectar las propiedades específicas del desarrollador. En las hormigas, por ejemplo:

<property environment="env" /> 
<property file="${basedir}/online/${env.LOGNAME}.build.properties" /> 
<property file="${basedir}/online/${env.USERNAME}.build.properties" /> 
<property file="${basedir}/online/default.properties" /> 

Si tiene LOGNAME conjunto con, por ejemplo, 'davec' y davec.build.properties existe, prevalecerá sobre cualquier valor en default.properties.

Esto también es útil para examinar las configuraciones de sus compañeros de trabajo para comenzar o diagnosticar problemas.

Answer 7

Si tienen que estar en el mismo repositorio, cree una carpeta "dev" o algo así y luego una subcarpeta para que cada desarrollador compruebe sus archivos de usuario.

O tenga un repositorio separado para los archivos del usuario.

O deje que el desarrollador individual lo haga con sus propios archivos.

Answer 8

Esto fue una especie de respuesta en una publicación anterior. Si bien la pregunta estaba más dirigida a WebApps, el problema real es exactamente lo que estás enfrentando ahora.

How do you maintain java webapps in different staging environments?

Answer 9

Nuestro proyecto es de configuración similar a otros en los que tienen algún tipo de archivo de propiedades únicas a la promotora, sin embargo, no creo que los archivos específicos de un solo desarrollador debe comprobarse en control de código fuente.

Tenemos un archivo personal.properties que se carga y anula los valores predeterminados del proyecto. El archivo está ubicado en el directorio de inicio de los usuarios. Para todos los valores que son específicos para el usuario, el valor predeterminado se establece así:

database_user_name = DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE 

El archivo nunca es editada por un desarrollador para que nadie información específica del usuario se registró en control de código fuente y si un desarrollador se olvida de establecer el valor en sus personal.properties archivo se produce un error obvio, como:

Unable to login to database with username: "DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE" 

Answer 10

Mantener un conjunto de valores por defecto en control de código fuente y luego o bien:

• HAV Cada desarrollador tiene un conjunto opcional de configuraciones que ellos mismos administran (ej. no se mantiene bajo control de código fuente) o

• tienen cada desarrollador mantener sus propias configuraciones de control de código fuente bajo algún tipo de esquema de identificación (username.properties como @Dustin utiliza)

La ventaja de mantener el desarrollador de configuraciones específicas en el control de fuente hace que sea fácil migrar de una computadora a otra (por ejemplo, en el caso de una falla de hardware o actualización). Es un simple svn co [repos] y hormiga

Answer 11

Usa plantillas, no agregas db-config al control de fuente (en realidad usas SVN: IGNORE en él), y añades db-config.tmpl o db-config .template o db-config.tmp o algo más que claramente le indique que es una plantilla.

Este archivo tiene la configuración básica y está destinado a ser copiado en 'db-config' (simplemente copiado deja la plantilla allí para recibir actualizaciones) para que cada desarrollador personalice.

Answer 12

Utilice git u otro sistema descentralizado de control de versiones. Luego, cada desarrollador puede mantener sus cambios privados en su propia sucursal privada, trabajar en esa sucursal y luego, seleccionar las características completadas de esa sucursal en el tronco principal del desarrollo.

Answer 13

Acabamos de mantener un estándar entre los desarrolladores. Todos usan los mismos directorios, nombres de bases de datos y usuarios, por lo que no tenemos que preocuparnos por esas cosas.

Saludos cordiales ajustes específicos