当对存储在Subversion repo中的软件进行编程时,我经常修改一些文件,然后注意到我想对我的主要工作做一些准备性更改。例如,在实现新功能时,我注意到一些重构可能会对我有所帮助。

为了不将两个不相关的更改混合在一起,在这种情况下,我想“收起”我的更改,即恢复到存储库版本,做一些其他更改,提交这些更改,然后“取回”我的更改。

Git-stash允许这样做。有没有办法在Subversion中直接或通过一些插件或脚本来做到这一点?Eclipse插件也可以。


当前回答

基于Walter的回答,我在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'

这些别名更容易使用和记忆。

用法:

svn。Stash用于保存更改,svn.stash.apply用于应用Stash。

其他回答

我也想要这个功能。我目前使用的是TortoiseSVN。

除了导出树,还原到存储库进行更改并提交,然后使用Beyond compare之类的工具将导出树中的更改比较回源代码控制目录之外,我还没有找到一个可靠的解决方案。

或者,另一种解决方案可能是从HEAD分支到另一个目录,进行更改并提交。一旦准备好将这些内容合并回其他工作副本,就可以进行更新并合并更改。

从1.10.0(2018-04-13)开始,您有实验性的svn shelve命令。(TortoiseSVN支持该命令)它只是一个保存补丁并应用回来的助手,因此它与svn diff + patch有相同的限制(即不能处理二进制文件和重命名)。(编辑:看起来下一个版本1.11.0将支持二进制文件)

编辑^2:1.11.0(发布2018-10-30)支持二进制文件。暂不支持搁置重命名的文件。1.11中的置物架与1.10中创建的置物架不兼容。

编辑^3:1.12.0(发布2019-04-24),支持复制和重命名。1.12中的货架与早期版本创建的货架不兼容。

编辑^4:1.13.0(2019年10月)和1.14.0(2020年5月)的搁置没有变化。命令仍被标记为实验性,需要定义SVN_EXPERIMENTAL_COMMANDS=shelf3才能启用该特性。看起来这个功能目前还没有分类。

设计说明可以在开发者的Wiki上找到。

$ 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

我总是保持第二次签出,我称之为“trunk_clean”。每当我需要做一个与我正在做的事情相关的快速、孤立的更改时,我就在签出时提交。

我想对上面提到的所有解决方案做一个总结,因为在这个问题下很混乱。一些高投票的答案是模棱两可的,我花了很多时间来证明答案的某些部分是真的还是假的。

解决方案:

签出一个新的工作副本并在新的副本中工作。(最简单最安全的方法) 创建分支→切换到新分支→blablabla(有人说这会在SVN服务器中产生一些垃圾) 创建补丁→还原工作副本→补丁返回(如果你没有任何未添加的文件或已删除的文件,则非常有用) 使用搁架(见下文)

我试了第1、2和3条。

第一条是最简单、最安全的。如果你想节省时间,可以使用这个解决方案。我知道这并不优雅。

#3不是我的选择,因为你可以用未添加的文件和现有文件的更改创建一个补丁。但它不会在创建补丁后删除那些未添加的文件。那么该怎么办呢?我必须创建一个补丁(选择未添加的文件)→恢复工作副本→手动删除所有未添加的文件。这一点都不像git -u那样。

# 4。Shelve将是git stash -u最优雅、最相似的一种方式。添加未添加/未跟踪的文件→搁置→完成。看到了吗?与git stash -u相比,唯一的区别是你必须先添加未添加的文件,然后搁置。


测试环境:

我正在测试所有使用Windows Tortoise SVN客户端使用网络共享副本(SAMBA)和Windows Tortoise SVN客户端创建的本地回购。

因此,如果您使用的是不同于本地共享的SVN服务器,我不知道情况会有什么不同。但我想架子在任何情况下都可以工作,因为它是本地操作。

你可以使用Intellij IDEA - Shelve Changes轻松做到这一点