0

我正在编写一个 shell 脚本，它可以存储 SVN 工作副本的实际状态并在以后恢复它，就像它一样。目前，我对似乎无法检测到的文件和目录修订的特定、罕见组合存在问题。

假设有一个包含两个修订版的存储库。有两种情况：

  1. 假设这foo是一个仅存在于修订版 2 中的文件（或目录）。一开始，整个工作副本位于修订版 2。然后foo（并且仅foo）更新到修订版 1。

  2. 假设这bar是一个仅存在于修订版 1 中的文件（或目录）。一开始，整个工作副本位于修订版 1。然后bar（并且仅bar）更新到修订版 2。

这两种情况非常相似，但似乎它们有不同的解决方案。在这两种情况下，文件（或目录）都会消失。但是，命令的输出不svn status包含有关此的信息。

如何通过 shell 脚本创建此类文件和目录的列表？

有一个简单但不好的解决方案。可以使用命令svn list获取当前版本中应该存在的文件列表，并将其与实际存在的文件列表进行比较。

这种解决方案是不可接受的，因为它需要大量时间并且会产生大量的服务器流量。

我发布了我能想到的最佳答案。尽管如此，它只适用于第一种情况并且有误报。

4

2 回答 2

2

我曾经试图做你正在做的同样的事情，我遇到了很多极端情况，最终我走向了完全不同的方向。我没有使用脚本，而是使用了本地 git 存储库。

从 Subversion 存储库中签出工作副本，然后在该文件夹中使用git init. 将 Subversion 工作副本的全部内容添加到 git 存储库 -包括元.svn数据目录 - 使用git add后跟git commit. Git 现在正在跟踪您的工作副本以及与之关联的所有 Subversion 元数据。我当前的 git 存储库有 5 个不同的分支，每个分支都基于不同的 Subversion 修订版，并包含尚未提交到 Subversion 存储库的不同更改集。git 存储库可以轻松地在它们之间来回切换，Subversion 就像它们都是独立的工作副本一样工作。即使对于大型工作副本，git 在有效存储内容和快速切换分支方面也做得很好。

请注意，这与命令不同，git svn命令是 git 直接与 Subversion 存储库交互的方法。我发现git svn使用起来更复杂，更容易破坏。在 git 存储库中包装一个普通的 Subversion 工作副本使我仍然可以使用 Subversion 执行所有存储库操作，并且只需要我学习一些基本的 git 命令（add、commit、branch、checkout等）。对于有 Subversion 经验和 git 新手的人来说，这会更容易一些；git svn更适合那些有 git 经验并坚持使用 Subversion 存储库的人。

于 2015-11-11T21:18:11.477 回答
0

我找到了第一种情况的部分解决方案。

svn status -u | grep '^........\*........ ' | cut -c 22-

此代码显示所有存在于头版本中但不存在于当前版本中的文件。这会从第一种情况中找到文件和目录。但是，当父目录（仍然存在）更新为较低版本时删除文件时，它会产生误报。

于 2015-11-05T22:38:37.310 回答