Supprimez temporairement les modifications non validées de Subversion (à la «git-stash»)

Lors de la programmation d'un logiciel stocké dans un dépôt Subversion, je modifie souvent certains fichiers, puis je remarque que j'aimerais effectuer des changements préparatoires pour mon travail principal. Par exemple, lors de la mise en œuvre de nouvelles fonctionnalités, je remarque une refactorisation qui pourrait m'aider.

Afin de ne pas mélanger deux modifications non liées, dans ces cas, je voudrais "ranger" mes modifications, c'est-à-dire revenir à la version du référentiel, effectuer d'autres modifications, les valider, puis "récupérer" mes modifications.

git-stash permet de faire exactement cela. Existe-t-il un moyen de le faire avec Subversion, soit directement, soit avec un plugin ou un script. Les plugins Eclipse seraient également très bien.

Lorsque j'ai des modifications non validées d'une tâche dans ma copie de travail et que je dois passer à une autre tâche, je fais l'une des deux choses suivantes:

1. Découvrez une nouvelle copie de travail pour la deuxième tâche.

   ou

2. Démarrer une succursale:

   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
   

J'ai quelques scripts qui aident à automatiser cela.

Ce billet de blog conseille d'utiliser diff et patch.

• git stash devient approximativement svn diff > patch_name.patch; svn revert -R .
• git stash apply devient patch -p0 < patch_name.patch

Notez que cela ne cache pas les modifications de métadonnées ou (je pense) que le répertoire crée / supprime. (Oui, svn suit ceux-ci séparément du contenu du répertoire, contrairement à git.)

Vous pouvez stocker vos modifications actuelles svn diffdans un fichier correctif, puis restaurer votre copie de travail:

svn diff > stash.patch
svn revert -R .

Après avoir implémenté votre fonction préparatoire, vous pouvez ensuite appliquer votre patch avec l'utilitaire de patch:

patch < stash.patch

Comme d'autres l'ont noté, cela ne fonctionnera pas avec svn:propertiesles opérations d'arborescence (ajouter, supprimer, renommer des fichiers et des répertoires).

Les fichiers binaires peuvent également poser des problèmes, je ne sais pas comment le patch (ou TortoiseSVN dans ce cas les gère).

La façon la plus simple serait d'utiliser une branche temporaire, comme ceci:

$ 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

Cela pourrait (et devrait probablement) être mis dans un script si cela était fait plus régulièrement.

Depuis la 1.10.0 (13/04/2018), vous disposez d'une svn shelvecommande expérimentale . ( TortoiseSVN prend en charge la commande ) Ce n'est rien d'autre qu'une aide pour enregistrer un patch et le réappliquer, il a donc les mêmes limitations que svn diff+ patch(c'est-à-dire qu'il ne peut pas gérer les fichiers binaires et les renommer). ( Edit : On dirait que le support binaire arrivera à la prochaine version 1.11.0 )

Modifier ^ 2: Avec 1.11.0 (publié le 2018-10-30), les fichiers binaires sont pris en charge . Le stockage des fichiers renommés n'est pas pris en charge. Les étagères en 1.11 sont incompatibles avec les étagères créées par 1.10.

Modifier ^ 3: avec 1.12.0 (publié le 2019-04-24), la copie et le changement de nom sont pris en charge . Les étagères en 1.12 sont incompatibles avec les étagères créées par les versions antérieures.

Edit ^ 4: Il n'y a aucun changement autour des rayonnages avec 1.13.0 et 1.14.0 . Les commandes sont toujours marquées comme expérimentales et vous devez définir SVN_EXPERIMENTAL_COMMANDS=shelf3pour activer la fonctionnalité. Il semble que la fonctionnalité ne soit pas actuellement testée .

Les notes de conception peuvent être trouvées sur le wiki des développeurs .

$ 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

Je ne connais pas de moyen facile de le faire avec juste svn. Honnêtement, je vous conseille d'utiliser git-svnpour faire un dépôt git qui agit comme une copie de travail svn, et de simplement l'utiliser git stashavec cela. Remplacez simplement git pullpar git svn rebaseet git pushpar git svn dcommitet vous pouvez réellement conserver 90% de votre flux de travail git et toujours parler à un serveur svn.

Il existe un petit script Python 2 appelé svn-stashdisponible sous GPL 3: https://github.com/frankcortes/svn-stash .

Il fonctionne comme les svn diff/patchsolutions mentionnées et offre des poussées et des sauts de modifications sous forme de différences dans un répertoire local. Malheureusement, les stashes ne peuvent pas être nommés, et seul le dernier peut être sauté (enfin, oui, c'est une pile, mais il n'y a pas vraiment de raison pour une telle limitation.) Mais alors, vous pouvez toujours intégrer les fonctionnalités manquantes dans le la source.

Il est écrit pour * ix, mais après avoir remplacé chaque "/", os.sepil fonctionne aussi bien sous Windows.

Si vous utilisez svn 1.7 ou supérieur, vous devez changer is_a_current_stash(): supprimez la ligne if ".svn" in os.listdir(CURRENT_DIR):, car il n'y a qu'un seul sous-répertoire .svn de niveau supérieur dans 1.7 WC.

Vous pouvez le faire facilement en utilisant Intellij IDEA - Shelve Changes

une autre option consiste à copier votre paiement actuel dans un nouveau répertoire et à annuler toutes vos modifications. De cette façon, vous éviterez les tracas de la création d'une branche temporaire sur votre serveur - après tout, le stashing est une opération locale, que tout le monde ne devrait pas voir et qui peut être effectuée assez souvent.

après avoir validé votre correctif, vous pouvez mettre à jour votre copie de travail principale et supprimer votre «zone de stockage»

J'ai également voulu cette fonctionnalité. J'utilise actuellement TortoiseSVN.

Je n'ai pas trouvé de solution fiable, sauf pour exporter l'arborescence, revenir au référentiel, apporter mes modifications et valider, puis comparer les modifications de l'arborescence exportée dans mon répertoire contrôlé par la source à l'aide d'un outil comme Beyond Compare.

Ou, une autre solution pourrait être de passer de la tête à un autre répertoire, d'apporter vos modifications et la validation. Une fois que vous êtes prêt à les fusionner dans votre autre copie de travail, effectuez une mise à jour et fusionnez vos modifications.

Je garde toujours un deuxième paiement, que j'appelle "trunk_clean". Chaque fois que j'ai besoin de faire un changement rapide et isolé lié à ce que je fais, je m'engage à la place.

Les idées de branchement et de correction ci-dessus sont excellentes, mais elles ne fonctionnent pas bien pour moi. J'utilise un outil de diff visuel, donc l'exécution git diffne produit pas de correctifs basés sur du texte. Notre système de construction crée un nouvel environnement chaque fois qu'une branche est créée, donc créer des branches "cachées" temporaires deviendrait compliqué.

Au lieu de cela, j'ai écrit un petit script shell qui copie un fichier dans un répertoire "étagère", ajoute un horodatage et annule la modification. Ce n'est pas aussi robuste que les solutions ci-dessus, mais cela évite également certains des pièges que j'ai rencontrés.

Sur la base de la réponse de Walter, j'ai créé les alias suivants dans mon fichier 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'

Ces alias sont beaucoup plus faciles à utiliser et à mémoriser.

Usage:

svn.stash pour cacher les modifications et svn.stash.apply pour appliquer la cachette.

Dans ma pratique, j'utilise git initpour créer un référentiel Git dans le trunkrépertoire de mon référentiel Subversion, puis j'ajoute *.gitaux motifs ignorer Suctions.

Après avoir modifié certains fichiers, si je veux continuer mon travail avec la ligne principale de Subversion, je l'utilise juste git stashpour ranger mon travail. Après m'être engagé dans le référentiel Subversion, je l'utilise git stash poppour restaurer mes modifications.

Utilisation:

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

Il créera une branche à partir de l'emplacement actuel et de la révision actuelle, puis il validera les modifications de la copie de travail dans cette branche sans y basculer.

utilisation: copie SRC [@REV] ... DST

SRC et DST peuvent chacun être un chemin de copie de travail (WC) ou une URL:

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

Notez que les modifications dans la copie de travail ne seront pas automatiquement annulées (il cps'agit simplement de modifications CoPying dans une nouvelle branche) et vous devez les annuler manuellement.

Pour restaurer les modifications, vous pouvez simplement fusionner les modifications de la branche nouvellement créée avec votre copie de travail.

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

--ignore-ancestry est utilisé afin de ne pas mettre à jour les informations de fusion dans la copie de travail.

Utilisation:

svn ls -v ^/trash-stash/

pour voir ce que vous avez sur le chemin caché. Les révisions engagées sont également imprimées.

Si vous n'avez plus besoin de la cachette, lancez simplement:

svn rm ^/trash-stash/my-stash

Cette solution est meilleure que d'utiliser le correctif, car si de nouveaux changements dans la copie de travail ou sur la branche actuelle entrent en conflit avec les changements dans la cachette, vous pouvez résoudre les conflits en utilisant les moyens svn, alors que patchdans certains cas, ils échoueront ou même appliqueront le correctif de manière incorrecte.

Étant donné que Subversion ne prend pas stashparfaitement en charge la fonctionnalité,
je fais simplement une méthode manuelle comme celle-ci.

Placer Developmentet Production(release)projeter sur un chemin séparé.

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

Vous pouvez travailler toutes les nouvelles fonctionnalités de votre projet dans le chemin de développement,
et vous ne feriez que des progrès significatifs ou quelque chose devrait être publié pour l'écurie.

Lorsque vous devez le publier pour la production, ouvrez le projet de production, mettez à jour svn et faites des choses à publier (génération, exportation, etc.).

Je sais que cela rend un peu gênant, mais publier des progrès ne se produit pas souvent (ce n'est pas le cas pour moi, mais je sais que certains projets le font) comparer pour développer des progrès, de cette façon me convient.

J'utilise svn pour des projets spécifiques depuis que les membres de l'équipe de projet l'utilisent, donc je dois suivre.
La meilleure solution est d'utiliser gitun système de contrôle de version parfait et meilleur que svn.