我正在编写一个shell脚本，它可以存储SVN工作副本的实际状态，并在以后恢复它，就像它一样。目前我对文件和目录的特定，罕见组合的修复存在问题，这些组合似乎无法检测到。
假设有一个包含两个修订版的存储库。 有两种情况：
假设foo是仅存在于修订版2中的文件（或目录）。一开始，整个工作副本位于修订版2.然后foo（仅{ {1}}）已更新为修订版1。
假设foo是仅存在于修订版1中的文件（或目录）。一开始，整个工作副本位于修订版1.然后bar（仅{ {1}}）已更新为修订版2。
这两种情况非常相似，但似乎它们有不同的解决方案。在这两种情况下，文件（或目录）都会消失。但是，命令bar的输出不包含有关该信息的信息。
如何通过shell脚本创建此类文件和目录的列表？
有一个简单但不好的解决方案。可以使用命令bar来获取当前版本中应该存在的文件列表，并将其与实际存在的文件列表进行比较。
此解决方案是不可接受的，因为它需要花费大量时间并为服务器带来大量流量。
我发布了我能想到的最佳答案。尽管如此，它仅适用于第一种情况并具有误报。
答案 0 :(得分：2)
我曾经尝试做过你正在做的事情，我遇到了很多角落，我最终走向了一个完全不同的方向。我没有使用脚本，而是使用了本地git存储库。
从Subversion存储库中查看工作副本，然后使用git init在该文件夹中创建一个本地git存储库。将Subversion工作副本的全部内容添加到git存储库 - 包括 {1}}元数据目录 - 使用.svn后跟git add。 Git现在跟踪您的工作副本以及与之关联的所有Subversion元数据。我当前的git存储库有5个不同的分支，每个分支都基于不同的Subversion修订版，并包含尚未提交给Subversion存储库的不同更改集。 git存储库可以很容易地在它们之间来回切换，而Subversion就像它们都是单独的工作副本一样工作。即使对于大型工作副本，git也能很好地有效地存储内容并快速切换分支。
请注意，这与git commit命令不同，后者是git直接与Subversion存储库连接的方法。我发现git svn使用起来更复杂，更容易破解。将一个普通的Subversion工作副本包装在git存储库中让我仍然可以使用Subversion完成所有存储库操作，并且只需要我学习一些基本的git命令（git svn，add，{{1 }，commit等）。对于有Subversion经验且对git不熟悉的人来说，这样会容易一些; branch更适合那些对git有经验并且坚持使用Subversion存储库的人。
答案 1 :(得分：0)
我找到了第一种情况的部分解决方案。
svn status此代码显示头版本中存在的所有文件，当前版本中不存在。这从第一种情况中查找文件和目录。但是，当父目录（仍然存在）更新为较低版本时，如果删除文件，则会产生误报。