1

我被要求解决由于不正确使用颠覆引起的问题（据我所知）。

这是历史，由于一段时间的流逝，用户的困惑等而受到损害，但这是我能弄清楚的最好的。预期目标是在给定时间点归档文件集（本质上是标记存储库，但用户不知道这一点）。

  • 用户已签出工作目录
  • 用户没有创建标签，而是通过 unix 复制命令（不是 SVN 移动或 SVN 复制）将文件复制到其工作副本中的子文件夹。
    • 例如，工作副本是 /var/tmp/working，他们将文件复制到 var/tmp/working/todays_date
  • 用户注意到这个新目录中缺少一些 .svn 目录，因此他们将 .svn 文件夹从另一个目录（他们不确定在哪里）复制到带有“标签”的目录中。

这是修复它的最佳方法吗？

想我会尝试以下：

  • 递归删除错误子目录中的所有 .svn 文件夹
  • 将目录从 repo 复制到本地
  • 在他们最后一次提交之前检查一个工作目录
  • 用“导出”文件覆盖新工作目录的文件
  • 完成正常的更新/提交过程
  • 创建标签

这是有道理的，还是我对其他问题敞开心扉？

其他问题

  • 它教育这个用户的最好方法是什么，这样他们就不会再这样做了？

更新：更多信息

从用户那里得到以下信息：

  • 我做了这项工作，然后尝试做一个 svn add。
  • 然后我做了 svn commit 这给了我一些错误。
  • 那时我移动了 .svn 文件，然后它终于做了 svn add 和 commit 没有错误
  • 但是 svn log 不显示提交的日志消息。

所以看起来用户复制了 .svn 文件夹以尝试进行提交，然后它显然确实添加并提交了，但我们不确定它是否这样做，因为我们在日志中找不到它。

4

3 回答 3

1

您应该只更新根 svn 文件夹。它将恢复已删除（移动）的文件，其他未被索引的文件将不会被触及。

然后可以使用 svn delete 命令清理，或者 svn move 或者 svn copy。但是，如果您这样做，您将丢失 ew“尚未编制索引的文件”和更改。所以也许，svn 删除更容易（但你会丢失历史，因为 svn 将无法知道新文件是从另一个文件移动）

于 2012-11-13T22:33:44.307 回答
0

正如我所见，你必须解决 2 个任务

  • 撤消主干中子目录周围的错误提交
  • 恢复用户的 WC

是的？

  1. 通过新提交撤消提交并反向合并错误提交
  2. 将用户的工作副本更新为此提交
于 2012-11-14T04:21:35.983 回答
0

因此，在与小组协商后，我们能够执行以下操作来解决此问题：

  • 备份文件夹
  • 使用 rsync 创建了没有 .svn 文件夹的文件夹结构的干净副本：

rsync -avr --exclude='.svn*' /originaldirectory /cleandirectory

  • 更新了工作副本
    • 事先确认此用户的更改是结构的这一部分中唯一重要的更改
  • 解决了优先使用用户的本地工作副本文件的冲突。
  • 试图提交以查找不正确的目录结构
  • 从文件结构中删除这些树并重新更新存储库以再次将它们拉下
  • 为了更好地衡量，用干净的文件覆盖所有文件内容以确保它们是最新的
  • 强制添加结构中的所有文件。
  • 坚定的。
  • 完成后创建一个标签。

不用说，我们很快就会和他们一起讨论 Subversion 的最佳实践。谢谢大家的指点！

于 2012-12-03T13:39:25.350 回答