我被要求解决因不正确使用subversion而导致的问题（据我所知）。
这是历史，它已经被一段时间的过去，用户混淆等所破坏，但这是我能想到的最好的。预期目标是在给定时间点归档文件集（主要是标记存储库但用户不知道这一点）。
- 用户已签出工作目录
- 用户通过unix复制命令（不是SVN移动或SVN复制）将文件复制到工作副本中的子文件夹，而不是创建标记。
- E.g。工作副本是/ var / tmp / working，他们将文件复制到var / tmp / working / todays_date
- 用户注意到这个新目录中缺少一些.svn目录，因此他们将.svn文件夹从另一个目录（他们不确定在哪里）复制到带有“tag”的目录中。
这是修复它的最佳方法吗？
想我会尝试以下方法：
- 以错误的子目录
递归删除所有.svn文件夹
- 将目录从本地仓库中复制出来
- 在上次提交之前查看工作目录
- 使用“已导出”文件覆盖新工作目录的文件
- 完成正常的更新/提交过程
- 创建标签
这是否有意义，或者我是否正在解决其他问题？
其他问题
- 它教育这个用户的最佳方式是什么，所以他们不会再这样做了？
更新：更多信息
从用户那里得到以下信息：
- 我做了工作，然后尝试做一个svn添加。
- 然后我做了svn提交，这给了我一些错误。
- 那时我移动了.svn文件，然后它最终做了svn add and commit而没有错误
- 但是，svn log不显示提交的日志消息。
所以看起来用户试图复制.svn文件夹以尝试提交工作，然后它显然添加并提交，除非我们不确定它是否因为我们在日志中找不到它。
3 个答案:
答案 0 :(得分：1)
您应该只更新根svn文件夹。
它将恢复已删除（移动）的文件，另一个未编入索引的文件将不会被触及。
然后你可以使用svn delete命令来清理，或者svn move或svn copy。但是，如果你这样做，你将失去新的“尚未索引的文件”和变化。所以也许，svn delete是easyer（但是你会失去历史记录，因为svn无法知道新文件是从另一个文件移动的）
答案 1 :(得分：0)
我必须解决2个任务，如我所见
- 撤消trunk
中subdir的错误提交
- 恢复用户的WC
是
- 通过反向合并错误提交撤消新提交的提交
- 将用户的工作副本更新为此提交
答案 2 :(得分：0)
因此，在与小组讨论后，我们能够执行以下操作来解决问题：
- 备份文件夹
- 使用rsync创建了没有.svn文件夹的文件夹结构的干净副本：
rsync -avr --exclude ='。svn *'/ originaldirectory / cleandirectory
- 更新了工作副本
- 事先确认此用户的更改是结构的这一部分中唯一重要的内容
- 已解决的冲突更喜欢用户的本地工作副本文件。
- 尝试提交以查找错误的目录结构
- 从文件结构中删除了这些树并重新更新了存储库以再次将其删除
- 为了更好地衡量，请用干净的文件覆盖所有文件内容，以确保它们是最新的
- 强制添加了结构中的所有文件。
- 提交。
- 完成后创建了一个标记。
毋庸置疑，我们很快就会与他们一起讨论Subversion的最佳做法。谢谢你的指点，全部！