$ 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
16 回答
当我从工作副本中的一个任务获得未提交的更改并且我需要切换到另一个任务时,我会执行以下两项操作之一:
要么
我有一些脚本可以帮助自动执行此操作 .
This blog post建议使用diff和patch .
git stash
大约成为svn diff > patch_name.patch; svn revert -R .
git stash apply
成为patch -p0 < patch_name.patch
请注意,这不会隐藏元数据更改或(我认为)目录创建/删除 . (是的,svn与目录内容分开跟踪,与git不同 . )
您可以使用
svn diff
将当前更改存储到修补程序文件中,然后还原您的工作副本:在实现预备功能之后,您可以使用修补程序实用程序应用修补程序:
正如其他人所说,这不适用于
svn:properties
和树操作(添加,删除,重命名文件和目录) .二进制文件也可能会出现问题,我不知道补丁(或者TortoiseSVN在这种情况下如何处理它们) .
最简单的方法是使用临时分支,如下所示:
如果更经常地进行,这可以(并且可能应该)放在脚本中 .
截至1.10.0(2018-04-13),您有实验svn shelve command . (TortoiseSVN supports the command)它只是保存补丁和应用的辅助工具,因此它具有与
svn diff
patch
相同的限制(即无法处理二进制文件和重命名) . ( Edit :Looks like binary support is coming at next version)Edit^2: 随着1.11.0(2018-10-30发布),二进制文件是supported . 搁置重命名的文件仍然不受支持 . 1.11中的搁架与1.10创建的搁板不兼容 .
设计说明可在Wiki找到 .
我不建议使用
git-svn
来制作一个作为svn工作副本的git仓库,并且只使用git stash
. 只需将git pull
替换为git svn rebase
并将git push
替换为git svn dcommit
,您实际上可以保留90%的git工作流程并且仍在与svn服务器通信 .在GPL 3下有一个名为
svn-stash
的小型Python 2脚本:https://github.com/frankcortes/svn-stash .它的工作方式与提到的
svn diff/patch
解决方案类似,并且可以将更改作为差异推送到一些本地目录中 . 不幸的是,stashes无法命名,只有最后一个可以弹出(好吧,是的,它是一个堆栈,但没有真正的理由存在这样的限制 . )但是,你可以随时将缺少的功能构建到资源 .它是为* ix编写的,但在用
os.sep
替换每个"/"之后,它在Windows下运行良好 .如果使用svn 1.7或更高版本,则需要更改
is_a_current_stash()
:删除行if ".svn" in os.listdir(CURRENT_DIR):
,因为1.7 WC中只有一个顶级.svn子目录 .您可以使用Intellij IDEA轻松完成 - Shelve Changes
另一种选择是将当前结帐复制到新目录并还原所有更改 . 通过这种方式,您可以节省在服务器上创建临时分支的麻烦 - 在所有存储都是本地操作之后,并非每个人都应该看到并且可以经常完成 .
提交修补程序后,您可以更新主要工作副本并删除“存储区域”
我也想要这个功能 . 我目前使用TortoiseSVN .
我没有找到一个硬解决方案,除了导出树,还原到存储库进行更改和提交,然后使用Beyond Compare等工具将导出树中的更改反馈回源控制目录 .
或者,另一种解决方案可能是从HEAD分支到另一个目录,进行更改和提交 . 准备好将这些内容合并回其他工作副本后,请执行更新并合并更改 .
我总是保持第二个结账,我称之为“trunk_clean” . 每当我需要做一个与我正在做的事情相关的快速,孤立的改变时,我只是提交了结账 .
上面的分支和修补思路很棒,但它们对我来说效果不佳 . 我使用视觉差异工具,因此运行
git diff
不会产生基于文本的补丁 . 每次创建分支时,我们的构建系统都会旋转一个新的环境,因此创建临时的分支会变得混乱 .相反,我写了一个little shell script,它将文件复制到"shelf"目录,添加时间戳,并还原更改 . 它不像上面的解决方案那么强大,但它也避免了我遇到的一些陷阱 .
根据Walter的回答,我在bashrc文件中创建了以下别名:
这些别名更容易使用和记忆 .
用法:
svn.stash用于存储更改并使用svn.stash.apply来应用存储 .
在我的实践中,我使用
git init
在我的Subversion存储库的trunk
目录中创建一个Git存储库,然后我将*.git
添加到Suctions忽略模式 .修改一些文件后,如果我想继续使用Subversion主线,我只需使用
git stash
来存储我的工作 . 在提交到Subversion存储库后,我使用git stash pop
来恢复我的修改 .使用:
它将从当前位置和当前版本创建一个分支,然后它将工作副本中的更改提交到该分支,而不切换到该分支 .
请注意,工作副本中的更改不会自动恢复(
cp
只是CoPying更改为新分支),您必须手动还原它们 .要恢复更改,您只需将新创建的分支中的更改合并到工作副本即可 .
--ignore-ancestry
用于不更新工作副本中的合并信息 .使用:
看看你在藏匿路径上有什么 . 还会打印承诺的修订版 .
如果您不再需要存储,只需运行:
此解决方案比使用补丁更好,因为如果工作副本或当前分支上的新更改与存储中的更改冲突,您可以使用svn方法解决冲突,而
patch
在某些情况下将失败甚至不正确地应用补丁 .由于Subversion不完全支持
stash
功能,我只是这样做手动方式 .
将
Development
和Production(release)
项目放在单独的路径中 .您可以在开发路径中为项目处理任何新功能,
你只会提出有意义的进展,或者应该为马厩发布一些东西 .
当你必须发布它用于 生产环境 ,打开 生产环境 项目,更新svn并做东西发布(构建,导出......等) .
我知道这有点麻烦,但发布进度并不经常发生(它不适合我,但我知道一些项目确实如此)与开发进度相比,这种方式适合我 .
我正在使用svn进行特定项目,因为项目团队成员使用它,所以我必须遵循 .
最好的解决方案是使用
git
,它具有完美的版本控制系统,优于svn
.