Guarde temporalmente los cambios no confirmados en Subversion (a la "git-stash")

Mientras programo el software almacenado en un repositorio de Subversion, a menudo modifico algunos archivos, luego me doy cuenta de que me gustaría hacer algún cambio preparatorio para mi trabajo principal. Por ejemplo, al implementar una nueva funcionalidad, noto algunas refactorizaciones que podrían ayudarme.

Para no mezclar dos cambios no relacionados, en estos casos me gustaría "guardar" mis cambios, es decir, volver a la versión del repositorio, hacer otros cambios, confirmarlos y luego "recuperar" mis cambios.

git-stash permite hacer exactamente eso. ¿Hay alguna manera de hacer esto con Subversion, ya sea directamente o con algún complemento o script? Los complementos de Eclipse también estarían bien.

Cuando tengo cambios no confirmados de una tarea en mi copia de trabajo y necesito cambiar a otra tarea, hago una de dos cosas:

1. Echa un vistazo a una nueva copia de trabajo para la segunda tarea.

   o

2. Comience una rama:

   workingcopy$ svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
   workingcopy$ svn switch SOME_BRANCH
   workingcopy$ svn commit -m "work in progress"
   workingcoyp$ svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE
   

Tengo algunos scripts que ayudan a automatizar esto.

Esta publicación de blog aconseja usar diff y patch.

• git stash aproximadamente se convierte svn diff > patch_name.patch; svn revert -R .
• git stash apply se convierte patch -p0 < patch_name.patch

Tenga en cuenta que esto no oculta los cambios de metadatos o (creo) que el directorio crea / elimina. (Sí, svn rastrea esos por separado del contenido del directorio, a diferencia de git).

Puede almacenar sus cambios actuales svn diffen un archivo de parche y luego revertir su copia de trabajo:

svn diff > stash.patch
svn revert -R .

Después de implementar su función preparatoria, puede aplicar su parche con la utilidad de parche:

patch < stash.patch

Como otros han señalado, esto no funcionará con svn:propertieslas operaciones en árbol (agregar, eliminar, renombrar archivos y directorios).

Los archivos binarios también podrían dar problemas, no sé cómo parchear (o TortoiseSVN en este caso los maneja).

La forma más fácil sería usar una rama temporal, como esta:

$ svn copy ^/trunk ^/branches/tempbranch
$ svn switch ^/branches/tempbranch
$ svn commit -m "Stashed"
$ svn switch ^/trunk
$ ... hack away in trunk ...
$ svn commit -m "..."
$ svn merge ^/branches/tempbranch .
$ svn rm ^/branches/tempbranch
$ ... continue hacking

Esto podría (y probablemente debería) incluirse en un script si se realiza de forma más regular.

A partir de 1.10.0 (13/04/2018), tiene un svn shelvecomando experimental . ( TortoiseSVN admite el comando ) No es más que un ayudante para guardar un parche y volver a aplicarlo, por lo que tiene las mismas limitaciones que svn diff+ patch(es decir, no puede manejar archivos binarios y renombrar). ( Editar : Parece que el soporte binario llegará en la próxima versión 1.11.0 )

Editar ^ 2: con 1.11.0 (lanzado el 10-10-2018), se admiten archivos binarios . La archivación de archivos renombrados permaneció sin soporte. Las estanterías en 1.11 son incompatibles con las estanterías creadas por 1.10.

Editar ^ 3: con 1.12.0 (lanzado el 24/04/2019), se admite la copia y el cambio de nombre . Las estanterías en 1.12 son incompatibles con las estanterías creadas por versiones anteriores.

Editar ^ 4: No hay cambios en las estanterías con 1.13.0 y 1.14.0 . Los comandos todavía están marcados como experimentales y debe definirlos SVN_EXPERIMENTAL_COMMANDS=shelf3para habilitar la función. Parece que la función no está actualmente actualizada .

Las notas de diseño se pueden encontrar en Wiki de desarrolladores .

$ svn x-shelve --help
x-shelve: Move local changes onto a shelf.
usage: x-shelve [--keep-local] SHELF [PATH...]

  Save the local changes in the given PATHs to a new or existing SHELF.
  Revert those changes from the WC unless '--keep-local' is given.
  The shelf's log message can be set with -m, -F, etc.

  'svn shelve --keep-local' is the same as 'svn shelf-save'.

  The kinds of change you can shelve are committable changes to files and
  properties, except the following kinds which are not yet supported:
     * copies and moves
     * mkdir and rmdir
  Uncommittable states such as conflicts, unversioned and missing cannot
  be shelved.

  To bring back shelved changes, use 'svn unshelve SHELF'.

  Shelves are currently stored under <WC>/.svn/experimental/shelves/ .
  (In Subversion 1.10, shelves were stored under <WC>/.svn/shelves/ as
  patch files. To recover a shelf created by 1.10, either use a 1.10
  client to find and unshelve it, or find the patch file and use any
  1.10 or later 'svn patch' to apply it.)

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  -q [--quiet]             : print nothing, or only summary information
  --dry-run                : try operation but make no changes
  --keep-local             : keep path in working copy

(...)

$ svn x-unshelve --help
x-unshelve: Copy shelved changes back into the WC.
usage: x-unshelve [--drop] [SHELF [VERSION]]

  Apply the changes stored in SHELF to the working copy.
  SHELF defaults to the newest shelf.

  Apply the newest version of the shelf, by default. If VERSION is
  specified, apply that version and discard all versions newer than that.
  In any case, retain the unshelved version and versions older than that
  (unless --drop is specified).

  With --drop, delete the entire shelf (like 'svn shelf-drop') after
  successfully unshelving with no conflicts.

  The working files involved should be in a clean, unmodified state
  before using this command. To roll back to an older version of the
  shelf, first ensure any current working changes are removed, such as
  by shelving or reverting them, and then unshelve the desired version.

  Unshelve normally refuses to apply any changes if any path involved is
  already modified (or has any other abnormal status) in the WC. With
  --force, it does not check and may error out and/or produce partial or
  unexpected results.

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  --drop                   : drop shelf after successful unshelve
(...)

$ svn help | grep x-
 x-shelf-diff
 x-shelf-drop
 x-shelf-list (x-shelves)
 x-shelf-list-by-paths
 x-shelf-log
 x-shelf-save
 x-shelve
 x-unshelve

No conozco una manera fácil de hacerlo con solo svn. Honestamente, recomendaría usarlo git-svnpara hacer un repositorio git que actúe como una copia de trabajo svn, y solo usarlo git stashcon eso. Simplemente reemplace git pullcon git svn rebasey git pushcon git svn dcommity realmente puede mantener el 90% de su flujo de trabajo de git y seguir hablando con un servidor svn.

Hay un pequeño script de Python 2 llamado svn-stashdisponible bajo GPL 3: https://github.com/frankcortes/svn-stash .

Funciona como las svn diff/patchsoluciones mencionadas y ofrece empujar y hacer estallar los cambios como diferencias en algún directorio local. Desafortunadamente, los escondites no se pueden nombrar, y solo el último se puede reventar (bueno, sí, es una pila, pero no hay una razón real para tal limitación). Pero entonces, siempre puedes construir las características que faltan en el fuente.

Está escrito para * ix, pero después de reemplazar cada "/" os.sepfunciona muy bien en Windows también.

Si usa svn 1.7 o superior, debe cambiar is_a_current_stash(): elimine la línea if ".svn" in os.listdir(CURRENT_DIR):, ya que solo hay un subdirectorio .svn de nivel superior en 1.7 WC.

Puede hacerlo fácilmente usando Intellij IDEA - Cambios de estantería

Otra opción es copiar su pago actual a un nuevo directorio y revertir todos sus cambios. de esta manera, ahorrará la molestia de crear una rama temporal en su servidor; después de todo, el ocultamiento es una operación local, que no todos deberían ver y que se puede hacer con bastante frecuencia.

después de confirmar su revisión, puede actualizar su copia de trabajo principal y eliminar su "área oculta"

También he querido esta característica. Actualmente uso TortoiseSVN.

No he encontrado una solución rápida, excepto para exportar el árbol, volver al repositorio, hacer mis cambios y confirmar, luego comparar los cambios del árbol exportado nuevamente en mi directorio controlado de origen usando una herramienta como Beyond Compare.

O, otra solución podría ser bifurcar desde HEAD a otro directorio, realizar sus cambios y confirmar. Una vez que esté listo para fusionarlos con su otra copia de trabajo, realice una actualización y combine sus cambios.

Siempre mantengo un segundo pago, al que llamo "trunk_clean". Cada vez que necesito hacer un cambio rápido y aislado relacionado con lo que estoy haciendo, solo me comprometo con ese pago.

Las ideas de ramificación y parcheo anteriores son geniales, pero no me funcionan bien. Utilizo una herramienta visual diff, por lo que ejecutar git diffno produce parches basados ​​en texto. Nuestro sistema de compilación crea un nuevo entorno cada vez que se crea una rama, por lo que crear ramas temporales "ocultas" se volvería complicado.

En cambio, escribí un pequeño script de shell que copia un archivo en un directorio "estante", agrega una marca de tiempo y revierte el cambio. No es tan robusto como las soluciones anteriores, pero también evita algunos de los escollos con los que me encontré.

Basado en la respuesta de Walter, he creado los siguientes alias en mi archivo bashrc:

alias svn.stash='read -p "saving local changes in raq.patch. Existing stash in raq.patch will be overwritten. Continue?[y/N]" && [[ $REPLY =~ ^[yY] ]] && rm -f raq.patch && svn diff > raq.patch && svn revert -R .'
alias svn.stash.apply='patch -p0 < raq.patch; rm -f raq.patch'

Estos alias son mucho más fáciles de usar y recordar.

Uso:

svn.stash para guardar los cambios y svn.stash.apply para aplicar el almacenamiento.

En mi práctica, uso git initpara crear un repositorio de Git en el trunkdirectorio de mi repositorio de Subversion, y luego agrego *.gita los patrones de ignorar Succiones.

Después de modificar algunos archivos, si deseo continuar mi trabajo con la línea principal de Subversion, solo uso git stashpara esconder mi trabajo. Después de comprometerme con el repositorio de Subversion, uso git stash poppara restaurar mis modificaciones.

Utilizar:

svn cp --parents . ^/trash-stash/my-stash

Creará una rama desde la ubicación actual y la revisión actual, y luego confirmará los cambios en la copia de trabajo a esa rama sin cambiar a ella.

uso: copia SRC [@REV] ... DST

SRC y DST pueden ser una ruta de copia de trabajo (WC) o una URL:

WC  -> URL:  immediately commit a copy of WC to URL

Tenga en cuenta que los cambios en la copia de trabajo no se revertirán automáticamente ( cpes solo Copiar los cambios a una nueva rama) y debe revertirlos manualmente.

Para restaurar los cambios, puede fusionar los cambios de la rama recién creada a su copia de trabajo.

svn merge --ignore-ancestry ^/trash-stash/my-stash -c <commited revision>

--ignore-ancestry se utiliza para no actualizar la información de fusión en la copia de trabajo.

Utilizar:

svn ls -v ^/trash-stash/

para ver lo que tienes en el camino oculto. Las revisiones comprometidas también se imprimen.

Si ya no necesita el alijo, simplemente ejecute:

svn rm ^/trash-stash/my-stash

Esta solución es mejor que usar el parche, ya que si los nuevos cambios en la copia de trabajo o en la rama actual entran en conflicto con los cambios en el alijo, puede resolver los conflictos utilizando medios svn, mientras que patchen algunos casos simplemente fallará o incluso aplicará el parche incorrectamente.

Dado que Subversion no admite la stashfunción perfectamente,
solo lo hago de forma manual como esta.

Colocar Developmenty Production(release)proyectar en un camino separado.

source\code\MyApp         -- Development
release\MyApp(release)    -- Production(release)

Puede trabajar cualquier característica nueva para su proyecto en la ruta de desarrollo,
y solo comprometería un progreso significativo o algo debería lanzarse para el establo.

Cuando tenga que lanzarlo para producción, abra el proyecto de producción, actualice svn y haga cosas para lanzar (compilar, exportar ... etc.).

Sé que esto es un poco problemático, pero la liberación del progreso no ocurre a menudo (no es para mí, pero sé que algunos proyectos sí) se comparan para desarrollar el progreso, de esta manera me queda bien.

Estoy usando svn para proyectos específicos ya que los miembros del equipo del proyecto lo usan, así que tengo que seguir.
La mejor solución es usar gitun sistema de control de versiones perfecto y mejor que svn.