上面的分支和补丁想法很棒，但对我来说并不管用。我使用一个可视化的diff工具，所以运行git diff不会产生基于文本的补丁。每次创建分支时，我们的构建系统都会旋转一个新环境，因此创建临时的“隐藏”分支会很混乱。

相反，我编写了一个小shell脚本，它将文件复制到“shelf”目录，添加时间戳，并恢复更改。它不如上面的解决方案健壮，但它也避免了我遇到的一些陷阱。

最简单的方法是使用一个临时分支，就像这样:

$ 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

这可以(而且可能应该)放在一个脚本中，如果更有规律的话。

Use:

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

它将从当前位置和当前修订创建一个分支，然后将工作副本中的更改提交给该分支，而不切换到该分支。

复制SRC[@REV]…DST SRC和DST都可以是工作副本(WC)路径或URL: WC -> URL:立即将WC副本提交到URL

注意，工作副本中的更改不会自动恢复(cp只是将更改复制到一个新的分支)，您必须手动恢复它们。

要恢复更改，只需将新创建的分支的更改合并到工作副本。

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

——ignore-ancestry用于不更新工作副本中的合并信息。

Use:

svn ls -v ^/trash-stash/

看看你藏东西的地方有什么。提交的修订版也被印刷。

如果你不需要了，就运行:

svn rm ^/trash-stash/my-stash

这种解决方案比使用patch更好，因为如果工作副本或当前分支的新更改与stash中的更改发生冲突，可以使用svn手段解决冲突，而patch在某些情况下会失败甚至不正确地应用patch。

这篇博文建议使用diff和patch。

Git stash大约变成SVN diff > patch_name.patch;svn revert -R。 Git stash应用变成补丁-p0 < patch_name.patch

注意，这不会隐藏元数据更改或(我认为)目录创建/删除。(是的，svn与目录内容分开跟踪，不像git。)

上面的分支和补丁想法很棒，但对我来说并不管用。我使用一个可视化的diff工具，所以运行git diff不会产生基于文本的补丁。每次创建分支时，我们的构建系统都会旋转一个新环境，因此创建临时的“隐藏”分支会很混乱。

相反，我编写了一个小shell脚本，它将文件复制到“shelf”目录，添加时间戳，并恢复更改。它不如上面的解决方案健壮，但它也避免了我遇到的一些陷阱。

另一种选择是将当前签出复制到一个新目录并恢复所有更改。这样就省去了在服务器上创建临时分支的麻烦——毕竟存储是一个本地操作，不是每个人都应该看到，而且可以经常这样做。

提交修复程序后，您可以更新主工作副本并删除“存储区域”