tortoise tag subversion new entre diferencia create crear branches svn

svn - tag - merge branches subversion



Subversión: evitar que se realicen modificaciones locales en un archivo. (13)

Agregue todos los archivos a una lista de cambios y luego elimine los archivos que no desea confirmar. Finalmente, realice la lista de cambios como se muestra a continuación:

$ svn status M file01 M ... M file100 M file_not_ready_for_commit // This will add all working copy files, can be adjusted to add only relevant files $ svn changelist mychangelist -R . // Remove the nascent one(s) $ svn changelist mychangelist --remove file_not_ready_for_commit // Commit only the files in the changelist $ svn commit --changelist mychangelist

La fuente de la información anterior es este blog que también tiene un enlace a http://svnbook.red-bean.com para más detalles. Todos los créditos para el autor del blog.

Tengo una copia de trabajo de Subversion donde hice algunas modificaciones locales a un archivo. Las modificaciones solo son relevantes para mí, no quiero comprometerlas. (La versión en el repositorio contiene algunos valores predeterminados que son adecuados para los otros usuarios, pero no para mí, y por eso quiero anularlos localmente).

Tenga en cuenta que, aunque no deseo comprometer mis cambios, sí quiero recibir actualizaciones realizadas en el repositorio cuando lo hago svn update . Además, es solo en mi copia de trabajo que no quiero confirmar los cambios en ese archivo, los otros usuarios no deberían verse afectados. Entonces svn:ignore o comprometer ganchos no se ajustan a mi propósito.

Actualmente, simplemente hago:

svn commit file1 file2...

donde especifico explícitamente los archivos que tienen cambios excluyendo el archivo particular que no quiero comprometer.

Sin embargo, mientras estoy trabajando, tengo el hábito de simplemente escribir:

svn commit -m "Log of what I just did"

y me temo que inadvertidamente cometeré el archivo "prohibido" utilizando el comando anterior en un momento en que no estoy atento.

En resumen, lo que estoy buscando es simplemente una forma de "marcar" un archivo en una copia de trabajo que evita que Subversion cometa los cambios en ese archivo (no tiene que ser una exclusión automática, incluso si acabo de recibir un error cuando intento enviar todos los archivos, está bien). Algo así como marcar archivos en un estado de "conflicto" ...

¿Existe tal cosa?

Actualización : akent, gracias por señalar esta pregunta muy similar .

Cree una lista de changelist con ese archivo y luego simplemente no preste atención a la lista de cambios. El archivo se quedará ahí esperando ser confirmado, pero sus confirmaciones regulares, que funcionan en la lista de cambios predeterminada, nunca lo recogerán.

svn changelist mylocal file1

creará una lista de mylocal llamada mylocal y le asignará el archivo file1 .

Desde mi experiencia: no pongas ese archivo bajo control de versión y usas svn: ignore en él.

Al principio es un poco difícil, ya que no puede ignorar un archivo que ya está bajo control de versión y no puede eliminar un archivo del control de versión sin eliminarlo del disco duro (y de cada copia de trabajo en la próxima actualización ...). Pero cuando finalmente logras configurar el repositorio correctamente, funciona como el encanto. No olvide agregar una plantilla genérica en lugar de su archivo de configuración original (para que todos conozcan las nuevas variables de configuración, etc.).

Para nuevo repositorio:

mkdir config svn add config svn propset svn:ignore ''*.conf'' config

Para el repositorio existente: asegúrese de tener una copia de seguridad de su configuración en cada copia de trabajo, luego elimine (svn del) config del repositorio, confirme (tenga en cuenta que el archivo se eliminará en cada copia de trabajo en la próxima actualización). tener una copia de seguridad) y luego restaurar el archivo y establecer la propiedad de ignorar.

Otra forma es un candado. Garantiza que nadie confíe el archivo, pero dará lugar a un error en cada confirmación. no muy bueno.

Y la tercera forma: changesets, una nueva característica en clientes SVN 1.5. Esto es claro, pero solo está relacionado con una copia de trabajo, no con un repositorio global. Y tiene que configurarlos manualmente, agregar cada nuevo archivo, es difícil de mantener.

Durante los últimos años he estado usando una solución simple que logra exactamente lo que está buscando. Se llama la palabra clave NOCOMMIT .

Lo que hago es que tengo un gancho precompromiso en mi repositorio SVN que comprueba si algún archivo contiene la cadena NOCOMMIT y, de ser así, falla la confirmación.

Entonces, cuando un programador realiza una modificación que no debe comprometerse (por ejemplo, cambiaron la cadena de conexión de la base de datos de todo el proyecto del servidor de prueba de toda la empresa a su propio servidor de prueba local, o agregaron sentencias de depuración de diagnóstico que van a envía correo basura al registro con miles de líneas por segundo), le añaden un comentario //NOCOMMIT , y no tienen que preocuparse de haberlo cometido accidentalmente. Cuando llega el momento de comprometerse, se previenen, por lo que se ven obligados a:

  • mover ese archivo a su lista de cambios de no realizar, o
  • busque NOCOMMIT y elimine cualquier aparición de este, con la esperanza de corregir el código al que lo había adjuntado.

Personalmente, considero que la palabra clave NOCOMMIT tan útil que la uso incluso cuando trabajo en proyectos de mascotas míos, donde obviamente soy el único programador del equipo.

Si está usando Windows, puede pegar el siguiente texto en el archivo llamado pre-commit.bat en la carpeta hooks de su repositorio SVN.

:: Stops commits that contain the NOCOMMIT keyword. setlocal set REPOS=%1 set TXN=%2 SVNLook diff %REPOS% -t %TXN% | findstr /I /M /L NOCOMMIT > nul if %errorlevel% gtr 0 ( exit 0 ) else ( echo Your commit has been blocked because it contains the keyword NOCOMMIT. 1>&2 exit 1 )

En los sistemas Unix, algo como lo siguiente debería ser el truco, aunque tenga en cuenta que no lo he probado.

#!/bin/sh REPOS="$1" TXN="$2" SVNLOOK=/usr/local/bin/svnlook $SVNLOOK diff -t "$TXN" "$REPOS" | grep -i "NOCOMMIT" > /dev/null && { echo "Your commit has been blocked because it contains the keyword NOCOMMIT." 1>&2; exit 1; }

En realidad, un script precompromiso haría el trabajo.

Escriba un script precompromiso que ejecute ''svnlook diff'' y rechace el commit si hay una propiedad llamada ''nocommit'' que se establece en el conjunto de cambios.

Luego, en su copia de trabajo, puede simplemente establecer una propiedad ''no comprometer'' en cualquier archivo que no deba comprometerse. Cualquier confirmación subsiguiente fallará si algún archivo tiene la propiedad ''no comprometer''. Si luego necesita verificar los cambios en el archivo, todo lo que tiene que hacer es eliminar la propiedad ''no comprometer'' de su copia de trabajo.

Entiendo el problema que estás teniendo; probablemente este archivo "prohibido" contenga ajustes de configuración y similares que solo son relevantes para su entorno de compilación local. No he encontrado ninguna manera directa de decirle a SVN solo para ignorar los cambios en un archivo versionado, pero aquí hay una solución que he usado en el pasado.

Suponiendo que su archivo es llamado, digamos, "build.conf". Nombre el archivo versionado SVN algo así como build.conf.example. Luego, en su script Makefile o compilación o lo que sea, puede copiar automáticamente build.conf.example al build.conf real , que permanece sin versión. Luego svn ignora build.conf y cada desarrollador puede hacer los cambios locales que necesite.

Pero "debe haber una mejor manera" ...

Editar: Pregunta casi idéntica aquí: SVN: ¿Hay alguna manera de marcar un archivo como "no confirmar"?

Esta pregunta está en las preguntas frecuentes de Subversion . Pero la respuesta no es muy útil si no controlas el repositorio.

Tal vez intente administrar su copia local con git además de la subversión. Hay un curso simple para git disponible. Luego puede usar git-svn para rastrear cambios en el repositorio svn y para comprometer sus cambios. Necesitará algo de aprendizaje y entrenamiento a través de.

Ha habido algunas respuestas que pueden funcionar:

  1. Cree un script de enlace previo a la confirmación que rechace el compromiso cuando se agrega una propiedad específica. A continuación, puede agregar esta propiedad a los archivos en la copia de trabajo para evitar confirmaciones.
  2. TortoiseSVN excluirá los archivos en la lista de cambios especial "ignorar-en-comprometer". Sin embargo, esto no es respetado por el cliente de línea de comandos SVN.

CoverosGene sugirió que los comandos predeterminados, como svn commit operan en una lista de cambios predeterminada, de modo que puede excluir un archivo si lo asigna a otra lista de cambios, pero no puedo encontrar ninguna referencia de eso en la documentación, y en mis pruebas este no funciona

Como no hay una buena solución para el cliente de línea de comandos SVN, he abierto una solicitud de mejora here . La solicitud sugiere que el cliente de línea de comandos también podría cumplir la lista de cambios "ignorar en el compromiso".

Actualización: ahora es el número 2858 y hay un esquema de características para manejarlo con una propiedad svn:hold .

Hablando de Tortoisesvn y listas de cambios, ya viene con una lista de cambios llamada ignorar-en-comprometer, que hace lo que estás buscando.

Lock ciertamente no es lo que quieres, y no creo que ninguna de las funciones integradas lo haga por ti.

Dependiendo del entorno en el que estés trabajando, escribiría un script que:

  1. Obtiene la lista de archivos
  2. Elimina los que no quiero comprometer
  3. Confirma los archivos

Algo como:

svn status | grep ^M | grep -v exclude.c | awk -F'' '' ''{print $2}'' | xargs svn ci -m "I''m committing something"

O si la lista de archivos es realmente estática, ¡solo arregla la lista!

Puede usar un gancho de precompromiso. En el gancho use svnlook author para ver si usted es el que está cometiendo los cambios. Si es así, use svnlook changed para ver si está cambiando uno de los archivos prohibidos.

Puede usar una sucursal personal y cambiar ese archivo para este efecto. Me gusta esto:

svn cp ^/trunk ^/branches/your_name -m "Creating a personal branch." cd working_copy_of_trunk/sub_path/ svn switch ^/branches/your_name/sub_path/your_file your_file

Tenga en cuenta que:

  1. Puede verificar el estado conmutado con la ''S'' que aparece en la quinta columna con el comando: svn status
  2. Nunca trabajará en la bifurcación, su working_copy_of_trunk aún está sincronizado con el directorio troncal del repositorio excepto los archivos que ha cambiado, de modo que siempre que realice cambios en su_archivo, las confirmaciones para ese archivo se realizarán en su bifurcación y no en el enlace troncal.

  3. La copia se ha realizado del lado del servidor completo, y esta es la forma recomendada con svn. La copia completa del lado del servidor es instantánea y no gastará espacio adicional en el servidor. Sin embargo, también se recomienda que las personas no revisen el directorio superior que contiene trunk / tags / y branches / pero directamente trunk / de lo contrario todos los archivos se duplicarán localmente al actualizar desde este directorio superior. Si este es el caso, sustituya el primer comando con:

    svn cp --parents ^ / trunk / sub_path / tu_archivo ^ / branches / tu_nombre / sub_path / tu_archivo

    Finalmente, si por alguna razón no desea copiar su archivo en otro lugar en su servidor de repositorio, entonces aún puede combinar este enfoque con un servidor externo y svn: palabras clave externas (no muy recomendadas).