当对存储在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。

其他回答

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

解决方案:

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

我试了第1、2和3条。

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

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

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


测试环境:

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

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

当我的工作副本中的一个任务有未提交的更改时,我需要切换到另一个任务,我会做以下两件事之一:

为第二个任务签出一个新的工作副本。 或 启动分支: workingcopy$ svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH workingcopy$ svn switch SOME_BRANCH Workingcopy $ SVN commit -m“正在进行的工作” workingcoyp$ svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE

我有一些脚本可以帮助实现自动化。

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

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

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

在GPL 3下有一个名为svn-stash的小Python 2脚本:https://github.com/frankcortes/svn-stash。

它的工作原理类似于前面提到的svn diff/patch解决方案,并提供了将更改作为diffs推入和弹出到某个本地目录的功能。不幸的是,存储不能被命名,只有最后一个可以被弹出(好吧,是的,它是一个堆栈,但没有这样的限制的真正原因)。但是,您总是可以将缺少的特性构建到源代码中。

它是为*ix编写的,但是在将每个“/”替换为os之后。sep它在Windows下工作得很好。

如果您使用svn 1.7或更高版本,您需要更改is_a_current_stash():删除如果“。在os.listdir(CURRENT_DIR):,因为在1.7 WC中只有一个顶级的。svn子目录。

由于Subversion不完全支持存储特性, 我就像这样手动操作。

将开发和生产(发布)项目放在一个分开的路径上。

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

你可以在开发过程中为你的项目添加任何新功能, 你只会承诺有意义的进展,或者应该为稳定释放一些东西。

当你必须将它发布到生产环境,开放生产项目,更新svn并做一些事情来发布(构建,导出…)等等)。

我知道这有点麻烦,但与开发进度相比,发布进度并不经常发生(对我来说不是这样,但我知道有些项目是这样),这种方式适合我。

由于项目组成员使用svn,所以具体项目我使用svn,所以我必须遵循。 最好的解决方案是使用git,它有完善的版本控制系统,比svn更好。