SVN：如何从“不相关”的分支创建适当的分支文件
我是 Subversion 的新手，我仍在根据大量预先存在的代码对我的一个存储库进行初始设置。我使用“主干”、“分支”和“标签”的传统术语。
我基本上有一个文件夹（后端），其中包含许多驱动实时生产站点的 php 文件，以及一个文件夹（backend_dev），其中包含为站点的开发版本提供支持的相同文件的变体。
我想最初设置我的存储库，以便 /trunk/php/ 包含来自“backend_dev”的文件，而 /branches/live-site/php/ 包含来自“backend”的文件。问题是我想以某种方式告诉 subversion 将我的分支作为分支正确处理，但由于该分支实际上与主干没有历史关系，所以最简单的 svn merge 用法似乎无法处理情况。
有办法做到这一点吗？如果没有，我应该遵循什么意识形态来处理我有多个（手动）版本的现有代码的情况。
需要明确的是，我尝试的是 svn 将我的“backend_dev”文件夹导入到 /trunk/php 并将 svn 将我的“backend”文件夹导入到 /branches/live-site/php 并使用 svn merge 来查看分支是否可以运行适当地。
I am new to Subversion, and I am still working on the initial setup of one of my repositories based on a good deal of pre-existing code. I am using the traditional nomenclature of "trunk", "branches", and "tags".
I essentially have a folder (backend) that has a number of php files that drive a live production site, and a folder (backend_dev) that has a variation of the same files that power a development version of the site.
I would like to initially set my repository up such that /trunk/php/ contains my files from "backend_dev" and /branches/live-site/php/ contains the files from "backend". The problem is that I would like to somehow tell subversion to properly handle my branch as a branch, but because the branch does not actually have a historical relationship with the trunk, the most simple svn merge usage does not seem to be able to handle the situation.
Is there a way to do this? If not, what is ideology I should follow to handle a situation where I have multiple (manual) versions of pre-existing code.
To be clear, what I have tried is to svn import my "backend_dev" folder to /trunk/php and svn import my "backend" folder to /branches/live-site/php and use svn merge to see if the branch would operate properly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议将生产代码导入主干，对其进行分支，然后将其替换为主干中的开发版本（根据需要进行任何添加和删除）并提交。
这样，生成的历史记录看起来就好像您从生产代码开始，对其进行分支，然后在主干中进行一些更改以达到开发版本 - 这大概（希望）或多或少符合实际情况。
I'd suggest importing the production code into trunk, branching it, and then replacing it with the development version in trunk (making any additions and deletions as needed) and committing.
That way, the resulting history will look as if you'd started with the production code, branched it, and then made some changes in trunk to arrive at the devel version — which presumably (hopefully) more or less matches actual reality.