update una tutorial trabajo tortoise revertir español copia comandos cambios svn revision svn-checkout

una - ¿Cómo se pueden verificar solo los archivos que se modificaron en un rango de revisiones SVN?



tortoise svn update (8)

¿Es posible verificar solo aquellos archivos de un repositorio SVN que fueron modificados en una revisión o rango de revisiones, sin verificar ningún archivo que no haya sido modificado?


Ahora hay una forma directa de obtener solo los archivos modificados y no todos.

Mi idea sería: usar la salida detallada de la lista (que muestra la última versión modificada), filtrarla a través de awk y verificar el resto. Por ejemplo, para buscar los archivos que cambiaron en la versión 42, usaría esto

VERSION=42 svn list -v -R -r $VERSION svn://... | awk "/^[ ]*$VERSION/ {print /$7}" > files_to_checkout

Y luego haga una svn update -r $VERSION ''cat files_to_checkout'' (o una co en la url, dependiendo de dónde ejecutará el comando).

EDITAR: Adicional incluso más corto: use el comando svn diff, y reemplace con -x y --diff-cmd el comando diff con svn co. Esto requiere un poco de modificación de argumentos (que no detallaré aquí), pero solo necesita una línea y ningún archivo intermedio (que también podría guardar arriba, pero eso hubiera costado legibilidad)


Hacemos esto en un script de MSBuild:

Paso 1: - Use el comando diff para obtener la lista de archivos modificados, redirija la salida a un archivo temporal en el directorio de destino Paso 2: - Lea el archivo temporal en un itemGroup

<Exec command="$(svnExecutable) diff -r $(StartRevision):$(EndRevision) $(DOUBLE_QUOTES)$(SvnRepositoryPath)/$(DOUBLE_QUOTES) --no-diff-deleted --summarize &gt; $(TempFilePath)" WorkingDirectory="$(WorkDirectory)" />


Mi sugerencia es la misma que sugiere flolo. Pero, toma un rango. Usted podría tener la siguiente función de shell.

function checkout_files_in_revrange() { svn_url=$1; start_rev=$2; end_rev=$3; for theCheckoutCanditate in `svn log -r $start_rev:$end_rev --verbose --incremental | grep " M " | cut -f5 -d'' '' | cut -f3- -d/` do svn co $svn_url/$theCheckoutCandidate -q; done }


No estoy completamente seguro de si esto es posible, pero también puedes hacer algo como esto:

svn checkout --revision <revisionNumber>

para obtener una cierta revisión y

svn log --revision <revisionNumber>

para listar todos los archivos en una revisión


Si usa svn log con la opción -v (verbosa):

svn log -r <revision> -v <path>

Obtendrá un resultado que incluye los archivos modificados:

r3 | ciaran | 2008-11-16 12:24:30 +0000 (Sun, 16 Nov 2008) | 1 line Changed paths: A /trunk/apache/apache.conf A /trunk/application/controllers Commit message goes here

Debería poder manipular eso con algo de grepping, etc. para producir una secuencia de comandos svn co.


En casi las mismas líneas que la mayoría de la gente ha sugerido, (sin embargo, solo en un sistema con grep y awk), puede obtener la lista ejecutando

svn log -v --revision <revision_number> | grep "^ " | awk ''{print $2}'' svn log -v --revision <revision_number> | grep "^ " | awk ''{print $2}'' .


Otra toma para responder tu pregunta:

Suponiendo que tiene una copia de trabajo existente, debería usar ''svn update'' en la raíz del directorio que contiene los archivos que está buscando, ya que recupera exactamente lo que cambió entre su revisión actual y la revisión HEAD con la menor cantidad posible de datos.

Los sistemas de administración de código fuente más antiguos, como CVS y VSS, preguntaron al servidor por cada archivo que ha cambiado este archivo. , mientras que la subversión simplemente envía los cambios de un árbol como una sola acción. Cuando pasas una lista de archivos para actualizar svn, no tienes esta ventaja.

Por lo tanto, la forma más eficiente de transferir lo que ha cambiado es simplemente actualizar. Esto solo transfiere una diferencia binaria de los cambios en HEAD en comparación con la versión base de su copia de trabajo.

Si el problema que está tratando de resolver es que la actualización de svn es lenta, entonces estamos tratando de resolver eso para Subversion 1.7.

Esta versión presentará un nuevo formato de almacenamiento de datos de copia de trabajo que hará que las operaciones simples que tienen que bloquear una copia de trabajo completa (como la actualización) mucho más rápido.


svn diff -r starting_revision: ending_revision_or_HEAD --summarize