svn导入混乱，后备箱上没有任何内容

我看了一下，它可能是适用的，但是，我有一个主干，但是开发人员，一个高级开发人员，将项目导入svn回购的方式可能会提供一个值得审查的差异

查看日志，开发人员似乎在本地创建了一个svn树，一个trunk/branchs/tags目录，在branchs目录中创建了所有文件，然后在初始导入到svn时，提交trunk和tags作为分支提交的一部分

这意味着没有复制到分支的历史记录。以近似保真度表示，日志为：

% cd work
% mkdir -p project/trunk project/branches project/tags
% cd project/branches
... begin a bunch of work on a java service v1.0
... happy lets import to svn
% cd ..
% pwd project
% svn import -m"Initial import"
A branches
A branches/file-n
A branches/file-n ...
A tags
A trunk
Sending...
Committed rn
% svn mv $repos/project $repos/project_name
...
Committed rn

所以svn合并在这里并不真正起作用。主干是初始提交的一部分，历史并不真正允许干净的合并

---

我可以使用复制和提交建议吗？或者在这种情况下，还有其他必要的方法吗？

我在这里结合了几件事情来解决这个问题

最终，这一举措不会对我们组织的构建过程起作用。这将使主干上的分支历史记录保持不变，但使分支为空。我们的构建不会喜欢这样

相反，我通过svn导出将文件复制到主干目录sans.svn目录，并提交它们

现在，有人可能会说，你刚刚失去了历史。我不太确定。分支的历史仍然存在，并且从主干创建了一个新分支。前一个分支保持活动状态，并且可以在流程允许、标记EOL等情况下停用

---

欢迎反馈。

我可能遗漏了一些东西，但听起来你的目标是将/branch/branch1/file1等的所有内容移动到/trunk/file1等。svn移动似乎可以解决这个问题……是的，也不是。如果trunk没有历史记录，我不能只将svn移动到trunk。这会将分支的历史记录带到主干，但会将分支留空。不幸的是，我们的构建过程会在这个基础上嘎嘎作响。不过我还是解决了。可能不是基于建议的，但它实现了我们组织认为可以接受的：将文件复制到trunk、commit和branch以获得新的发布行。