合并多个 SVN 存储库
我正在尝试将多个源存储库合并在一起，并在此过程中维护版本历史记录。我已经阅读了大量关于 svnadmin 转储/加载过程的文章，但是我仍然缺少一部分。
每个源存储库都使用标准的“主干”和“分支”设置进行设置。这一切都很好。问题是当我将东西合并在一起时我想调整路径。例如...
我见过的许多方法都允许您创建这样的结构：
/project1
/project1/trunk
/project1/trunk/html
/project1/branches
/project2
/project2/trunk
/project2/trunk/html
/project2/branches
但是，我希望我们的最终结构是这样的：
/trunk
/trunk/project1
/trunk/project1/html
/trunk/project2
/trunk/project2/html
/branches
原因是：所有项目都是交织在一起的。 Project1 可能是我们的后端软件，project2 是我们的前端软件，project3 是我们的 cron 作业，等等。基本上，这都是一个组合系统，而项目特定的分支似乎只会让我们的生活变得更加困难。
也就是说，问题在于我如何将旧目录结构转换为新目录结构。想法？
I'm trying to merge multiple source repositories together, maintaining version history during the process. I've been doing a lot of reading on the svnadmin dump/load process, but there's one piece that I'm still missing.
Each source repository is setup with your standard "trunk" and "branches" setup. That's all good. The problem is that I want to massage the paths when I merge things together. For instance...
Many of the approaches that I've seen would allow you to create a structure this this:
/project1
/project1/trunk
/project1/trunk/html
/project1/branches
/project2
/project2/trunk
/project2/trunk/html
/project2/branches
However, I want our final structure to be like this instead:
/trunk
/trunk/project1
/trunk/project1/html
/trunk/project2
/trunk/project2/html
/branches
Reason being: All of the projects are intertwined. Project1 might be our backend software, project2 our front-end software, project3 our cron jobs, etc. Basically, it's all one combined system, and project specific branching seems to just make our life more difficult.
That said, the problem arises with how I translate the old directory structure to the new. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它可能会满足您的需要，即按原样合并存储库，并进行单独的分支，然后在新的合并存储库中移动内容，以便最新版本包含您想要的文件。这比尝试编辑历史记录的工作量要少，并且您仍然保留历史记录，尽管您可能需要在复制后打开显示历史记录。然后，即使检查旧修订版将内容放在错误的位置，您也可以获得新修订版的首选结构。
It may meet your needs to merge the repositories as is, with separate branching, then to move things around in the new, merged repo so that the latest revision has the files where you want them. This is less work than trying to edit history and you still preserve your history, although you may need to turn on showing history after copy. You then get your preferred structure for new revisions, even if checking out old revisions puts things in the wrong place.
我的方法是使用正常的 svn move 和 svn copy 命令预先准备“新”结构，然后进行转储和复制。之后加载。
尝试使用 svndumpfilter 以适合新存储库的格式处理转储文件非常复杂且容易出错。
The way I would do it is by preparing the "new" structure up front with normal
svn moveandsvn copycommands and do the dump & load afterwards.Trying to massage the dump file with
svndumpfilterin a format that fits your new repository is complicated and error prone.