SVN 并行分支

Posted 2023-02-19

【中文标题】SVN 并行分支

【英文标题】：SVN parallel branches

【发布时间】：2021-01-14 04:00:48

【问题描述】：

我学习了一些关于如何使用分支/合并在团队中工作的 SVN 教程，但在流程中仍然无法正常工作。 我在局域网中使用 Tortoise SVN + Visual SVN 服务器。有 N 个开发者。

场景 1：分支在主干内

Developer-A 从 http://svn-server/OurProject 签出“OurProject”生产版本。一开始没有分店。 Developer-A 在主路径下创建“Branch-A”，所以 http://svn-server/OurProject/Branch-A。他将工作文件夹切换到分支并开始编码。他添加了一些文件并编辑了一些其他文件。他将更改提交到分支。 Developer-B 对他同事的工作和他的分支一无所知，所以他只是从 http://svn-server/OurProject 中检查了整个“OurProject”。这导致 Developer-B 检查整个“OurProject”结构，以及“Branch-A”文件夹！这对我来说是第一个奇怪的事情。 Developer-B 在路径 http://svn-server/OurProject/Branch-B 处启动一个新的“Branch-B”分支并开始编码。 开发人员 B 完成编码，而开发人员 A 仍在工作。他将他的 Branch-B 合并到项目根目录中并提交。这导致开发人员 B 从主干中删除了“Branch-A”！ 不，我认为这不是正确的解决方案。

场景2：分支在主干之外（从分支合并到主干）

Developer-A 从 http://svn-server/OurProject/trunk 查看“OurProject”生产版本。一开始没有分店。 Developer-A 在“branches”子文件夹下创建“Branch-A”，所以 http://svn-server/OurProject/branches/Branch-A。他将工作文件夹切换到分支并开始编码。他添加了一些文件并编辑了一些其他文件。他将更改提交到分支。 Developer-B 对他同事的工作和他的分支一无所知，所以他只是从 http://svn-server/OurProject/trunk 查看整个“OurProject”。这导致 Developer-B 只检查生产代码，而看不到同事的分支。很好。 Developer-B 在路径 http://svn-server/OurProject/branches/Branch-B 处启动一个新的“Branch-B”分支并开始编码。 开发人员 B 完成编码，而开发人员 A 仍在工作。他将他的 Branch-B 合并到项目根目录（从分支到主干）并提交。这会导致主干覆盖所有“Branch-B”修改！不对。

场景 3：分支在主干之外（从主干合并到分支）

...（与上一个场景相同，除了最后一点）

开发人员 B 完成编码，而开发人员 A 仍在工作。他将他的 Branch-B 合并到项目根目录（从主干到分支）并提交。这会导致 Tortoise SVN 冲突警告。我选择“标记为已解决，接受当前工作副本状态”。 Developer-B 切换到主干，SVN 删除我的新分支文件，我的所有分支修改再次丢失。

经过数十次尝试后，我想知道哪个是真正的流程。 感谢您的帮助

【参考方案1】：

您的项目布局似乎无效。您是否在项目的根目录中创建了/trunk？

请阅读 SVNBook：

The Copy-Modify-Merge solution Planning Your Repository Organization Branching and Merging

场景 1：分支在主干内

您不需要将树枝存放在树干或其他树枝内。你在这个场景中描述的项目布局是不正确的，将来肯定会让你头疼。此外，使用这种布局，您将 - 默认情况下 - 当您只想签出主干时签出所有分支。

您似乎认为 /OurProject 是您项目的主干，但事实并非如此，也不应该如此。如果您更喜欢使用常见的“主干、分支、标签”布局，那么您的项目的根目录应该包含以下目录：

branches/ https://svn.example.com/MyRepo/MyProject/branches
tags/     https://svn.example.com/MyRepo/MyProject/tags
trunk/    https://svn.example.com/MyRepo/MyProject/trunk

场景2：分支在主干之外（从分支合并到主干）

...

开发人员 B 完成编码，而开发人员 A 仍在工作。他将他的 Branch-B 合并到项目根目录（从分支到主干）并提交。这会导致主干覆盖所有“Branch-B”修改！不对。

通常，主干！=您项目的根。如果您合并从 /branches/MyBranch 到 /trunk 的更改，一旦提交，来自您的分支的更改将出现在主干中。即，您是reintegrating the branch changes back to trunk。

这同样适用于您的场景 3。但是，如果您“将 Branch-B 合并到项目根目录（从主干到分支）”，则您正在同步您的分支与自创建此分支以来对主干所做的更改。即，您是keeping the branch in sync with trunk。

【参考方案2】：

不要在 2020 年使用 SVN，它仅适用于具有悠久历史和懒惰的 devops 的真正古老的大型项目（以及您范围之外的其他一些罕见情况） . “Merge Hell”在 Subversion 中是真正的痛苦，无法避免 如果您仍然停留在 SVN：

阅读 SVN 书 选择首选的回购树 定义、声明和遵循开发政策（待定、BranchPerTask 等）和访问规则

毕竟，您将获得所有 3 个用例的所有答案。 1只是丑陋无用的风格，2-3：SVN删除nothing，阅读关于在SVN中移动历史，选择树等

【讨论】：

在你看来，2020年我应该去做什么？吉特？

@Marco - 我讨厌大部分无脑 Git 男孩，不喜欢 Git。我今天的选择是 Mercurial（THG - 快速入门）

@Marco 遗憾的是 git 不适用于具有大型二进制文件的项目。 （Unity、FBX、媒体资产）对于多类型资产项目的本地托管配置管理来说，这是一个很好的替代方案。