如何在SVN仓库中合理规划需定期合并的codeA与codeB代码结构

问题1：codeA与codeB是否应该拆分为独立仓库 #

不建议拆分为独立仓库。
SVN原生不支持跨仓库的合并跟踪能力，如果拆分仓库，每次把codeA的更新同步到codeB时，都需要人工记录已经合并的版本号，很容易出现漏合并、重复合并的问题，长期维护的出错概率和操作成本都会大幅上升。
如果强制使用独立仓库方案，只能按以下逻辑定义角色，但该方案没有SVN原生特性支撑，不推荐使用：

• codeA仓库的trunk作为上游基准分支，所有codeA的更新都提交到该路径
• codeB仓库的trunk作为业务开发主线，接收codeA的同步更新和团队自定义开发提交

问题2：是否可以将codeB作为trunk，codeA作为分支，直接合并更新 #

这个方案完全符合SVN的copy-modify-merge工作流设计，是最优选择，具体落地步骤如下：

• 初始化单仓库的标准结构，根目录下创建trunk和branches两个一级目录
• 将当前codeB的全量代码提交到trunk目录，作为团队开发的主线，给所有参与codeB开发的人员开放该路径的读写权限
• 基于trunk的初始提交版本执行svn copy命令，生成branches/codeA上游同步分支，将当前维护的codeA全量代码覆盖提交到该分支，仅给codeA的维护人员开放该路径的读写权限，其他开发者仅开放读权限
• 后续codeA的所有更新都正常提交到branches/codeA分支
• 需要同步codeA更新到codeB时，直接将codeA分支的提交合并到trunk即可，SVN会自动记录合并历史，不需要人工维护同步节点，合并过程中出现的代码冲突按常规流程处理后提交即可

额外优化建议 #

• 固定codeA到trunk的同步周期，比如每周固定同步一次，避免大量提交堆积导致冲突处理成本上升
• 每次同步完成后打一个标签记录同步版本，方便后续出现问题时快速回滚

内容的提问来源于stack exchange，提问作者Daniel Klisiewicz