SVN confirmación atómica cómo-a

Estás en: línea de comandos de LinuxSVN confirmación atómica cómo-a

El problema que tengo ahora:

A veces no podía hacer commit atómicos (que consisten todas las modificaciones requeridas por un boleto especial/tarea), porque tenemos algunos archivos en el repositorio, cuyos contenidos varían en los entornos de desarrollo locales.

Por ejemplo: database.xml (dbname, nombre de usuario, contraseña, etc.). Modifico este archivo en mi entorno local, y cada vez que necesito hacer un commit/checkin he enumerado manualmente todos los archivos/carpetas requeridos para el commit (excluyendo estos archivos modificados localmente).

tal vez es una decisión de diseño equivocado y database.xml tiene que ser eliminado del repositorio y cambiado para database.xml.template (almacenado en SVN), por lo que este archivo no será incluido para comprometerse hasta que ejecute manualmente svn add por ello? Tal vez sea un enfoque incorrecto: almacenar toda esta información dependiente del entorno en el repositorio; en ese caso podemos romper todo al comprometer una configuración modificada, por ejemplo ...

Según tengo entendido, la propiedad svn:ignore no pudo ayudar esta situación, porque se puede usar solo para archivos que no están almacenados en el repositorio ..

¿Cómo se puede resolver este problema?

P.S .: Estoy usando Ubuntu y la línea de comandos pura en su mayoría para SVN.

Fuente

2009-05-03 ep3static

Estoy de acuerdo con mantener un archivo '.template' en Subversion y la configuración real, versión modificada, solo localmente.Es importante que los desarrolladores * nunca * modifiquen el archivo de configuración real para una configuración que no sea personal. Es decir, si se va a agregar una nueva opción al archivo, debe agregarse al archivo '.template' y luego volver a crear su propio archivo de configuración (tal vez automatizar la reconstrucción de la configuración desde' .template' archivo con una secuencia de comandos para facilitar el trabajo). –

Sí, tendría database.xml.template en SVN, database.xml.override en los checkouts locales e ignorado, y un script para combinar los dos para producir database.xml. Al menos, lo haría si tuviera tiempo para escribir el guión ;-) De lo contrario, los desarrolladores tienen que hacer una fusión manual en databaes.xml cada vez que cambie database.xml.template. –

De hecho, si los desarrolladores quieren ser realmente sofisticados, pueden hacer que database.xml.override un enlace rígido a un archivo que controlan las versiones en su rama personal del repositorio, para que la configuración personal también esté controlada. –

El procedimiento "estándar" para esto es algo como esto (perdonando la sintaxis SVN, He estado usando Bazaar últimamente):

echo config > database.xml.template 
svn add database.xml.template 
svn ignore database.xml 
svn commit

Luego, el equipo de desarrollo de cada persona:

svn checkout 
cp database.xml.template database.xml 
...edit database.xml...

Y cuando se comprometen,

echo foo > someotherfile 
svn commit

laEl archivono se agregará a Subversion.

Fuente

2009-05-03 10:26:46 FryGuy

el comando real para hacer que svn ignore database.xml sería "svn propset svn: ignore database.xml". (a partir de svn 1.5.5) – che

Si recuerdo correctamente usar propset anulará todas las demás svn: ignore en su lugar. Podría intentar combinar propget y propset o, más fácilmente, apropiar y usar el editor para agregar otra línea. –

Debe almacenar una plantilla en el repositorio, pero no el archivo real que necesita modificar localmente.

De esta manera puede reconstruir un archivo prístino, si lo necesita, sin arriesgarse a almacenar un archivo en el repositorio que no debería estar allí.

Y no, svn: ignorar no te ayudará aquí.

Fuente

2009-05-03 10:22:25

Mis 2 centavos: Antes que nada, debe asegurarse de que haya alguna forma (fácil) de armonizar sus rutas para todos los desarrolladores involucrados en su proyecto. Esta puede ser la misma estructura de directorio relativa o alguna capa delgada en su aplicación que admita algunos shell vars o tales como $ home,% USERPROFILE% etc. Esto sería mucho más conveniente en el tiempo que dejar que cada desarrollador maneje su propia configuración no versionada y eso es lo que los IDEs intentan proporcionar también.

En general, los archivos de configuración de versionado están perfectamente bien para mí, es simplemente el tiempo que un desarrollador pasó a configurar y no debe perderse por accidente.

Fuente

2014-08-11 08:03:35

Respuesta

Cuestiones relacionadas