您真的不需要为Test、Production和Development单独的代码行。除非您希望测试和生产中的人员自己编写代码。否则，您将来回复制很多东西。
开发人员正在处理的修订版（假设是 Subversion 修订版 #100）将在一段时间后由 QA 团队进行测试。而且，如果 QA 团队喜欢它，修订版 #100 将发布到生产环境中。每个团队都跟随另一个团队。也许那些正在开发中的人正在开发 Subversion Revision 100。与此同时，QA 正在测试 Revision 97。而且，Revision 90 正在生产中。我唯一推荐的是标记投入生产的内容。
我们来看一个典型的结构：
repo/branches/
repo/tags
repo/trunk/common
repo/trunk/projects
我在项目的主干上工作foo。我检查repo/trunk/foo并repo/trunk/common做我的工作并检查我的更改。
现在，假设我想在我的后备箱上标记修订版 90，因为它已被批准用于生产，我可以像这样标记我的版本：
$ svn cp --parents -r 90 $REPO/trunk/foo@90 $REPO/tags/1.3/foo
$ svn cp -r 90 $REPO/trunk/common@90 $REPO/tags/1.3/common
如果我需要查看发布的内容，我可以从我的存储库中查看 1.3 发布标签。
通常有两种方式使用分支：
我将描述发布分支，因为它更容易。
想象一下，您正在开发 1.3 版本。在某些时候，您的一些开发人员在您的 1.3 版本上没有更多工作要做，并且想要在 1.4 版本上工作。
到目前为止，您的 1.3 版本的工作是在主干上完成的。您的 1.4 开发人员无法完成他们的工作，因为他们不想在您进行 1.3 代码更改时进行 1.4 更改。所以，他们整天坐在那里玩 Candy Crush，直到 1.3 完成，每个人都可以在 1.4 发布时脱离主干工作。
为了减少 Candy Crunch 的时间，我将创建一个发布分支：
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.3/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.3/common
现在，那些仍在开发 1.3 版的开发人员将他们的工作副本切换到 1.3 分支，而那些在 1.4 上工作的开发人员仍然在主干上工作。发布完成后，您可以立即在分支上对其进行标记：
$ svn cp --parents $REPO/branches/1.3/foo $REPO/tags/1.3/foo
$ svn cp $REPO/branches/1.3/commons $REPO/tags/1.3/commons
当版本 1.4 接近时，您冲洗并重复。
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.4/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.4/common
现在，那些在 1.5 版上工作的人继续在主干上工作，而在 1.4 版上工作的人在分支上工作。
如果您需要进行热修复怎么办？说版本 1.4 中存在错误？您已经有一个 1.4 分支，我认为当版本 1.4 发布时不再使用它（检查起来很容易。将 1.4 分支上的最新版本与制作 1.4 标记的版本进行比较）。只需在 1.4 分支上为 1.4.1 版工作。
如您所见，事情并没有那么复杂。顺便说一句，你也没有理由不能颠倒名称：
$REPO/foo/trunk
$REPO/foo/branches
$REPO/foo/tags
$REPO/common/trunk
$REPO/common/branches
$REPO/common/tags
在这种情况下，我将每个项目视为具有自己的分支和标记的单独子存储库。如果我所有的项目都在不同的发布时间表上，我可能想这样做。
回复
好的，所以我在公共文件夹下已经有了“主干/分支/标签”。所以我猜我可以完全删除 Dev/Test/Prod 文件夹（以及 prod 的内容）。“测试”实际上将位于 Repo/foo/branches/test 中，对吗？或者我猜它可以去 Repo/branches/test/foo/，对吧？（常见的是设置为 SVN 外部...仅供参考）
不需要测试分支。QA 只是在开发人员正在使用的分支上测试特定的 Subversion 版本。例如，假设 Subversion 使用的是 Revision 100，而 QA 正在测试 Revision 95。如果 QA 发现一个错误，它会被报告并合并到 Revision 101。当 QA 测试 Revision 101 或更高版本时，他们可以测试该错误是否存在已修复。如果有，他们可以关闭该错误。否则，他们可能会重新打开它。
如果您使用像Jenkins这样的持续集成系统，它会在每次更改时构建您的软件，那么您可能正在谈论一个特定的构建。最后一个版本将是 Build #30，但 QA 正在测试 Build #28。如果 QA 发现错误，开发人员将简单地修复它，Jenkins 将生成 Build #31。然后 QA 可以测试 Build #31 以查看错误是否已修复。
我们在一个商店中使用了 Jira 和 Jenkins，并且将它们集成在一起。当开发人员修复错误时，他们会将错误编号放入提交消息中。然后，Jenkins 将使用 Jenkins 构建更新该 Jira 票证。如果 QA 发现一个已解决的问题，他们可以查看 Jira 票证，查看已修复问题的 Jenkins 构建并对其进行测试。
我希望这是有道理的，以及为什么您不需要用于测试、生产等的分支。
因为我根本没有使用过 SVN 语法，所以我需要去研究 --parents 的东西......我们只使用 Tortoise，但我想我可能还是需要学习 SVN，因为这是使用 Jenkins构建...
了解 Subversion 客户端的命令行版本总是好的。有时，当 TortoiseSVN 出现问题时，您可以从命令行客户端获取更多信息以查看发生了什么。该--parents参数仅表示创建可能存在或不存在的父目录。例如，您要创建目录/branches/4.3/foo，但可能没有/branches/4.3目录。在 TortoiseSVN 中，我相信这会自动创建。在命令行客户端中，该--parents参数将创建/branches/4.3目录（如果不存在）和/branches/4.3/foo目录。
您回答中的其他所有内容看起来都很棒！我只有一点 Git 背景，有很多 SourceGear Vault 背景，所以切换还是有点混乱。
与 Git 相比，Subversion 实际上非常简单，因为只有一级存储库。您签出、修改、提交。
Git 和 SVN 的最大区别在于 SVN 是线性的。修订版 100 总是在修订版 101 之前。在 Git 中，修订版没有真正的顺序。存储库修订表示为带有校验和的blob 。该顺序是由指向特定blob的树强加的。但是，对于熟悉 SVN 的人来说，理解 Git 可能比反过来更难。
等等，还有一个问题，如果分支名称会在每个版本（即 1.3、1.4 等）都发生变化，我将如何为我的测试环境自动构建？
在 Jenkins 中，我们只是有一堆复制项目的 shell 脚本。我已经设置了项目，因此它们之间的变化很小：我只是更改了分支名称。运行我的脚本，很快就会创建更多 Jenkins 作业。运行另一个，旧的分支作业被删除。
一些站点使用提交后触发器来构建发生在分支上的 Jenkins 作业。在 Jenkins 中，您可以将参数传递给构建，因此您可以传递发生更改的分支，然后 Jenkins 在该分支上构建。当他们从一个版本转移到另一个版本时，他们永远不必创造新的工作。
现在，如果您每周或每两周发布一次，您可能不需要发布分支。一切都脱离了主干（除了偶尔的热补丁）。在这种情况下，很可能您团队中的每个人都在开发同一个版本。我进行分支是为了让两组不同的开发人员同时在版本 1.3 和 1.4（在主干上）工作。如果您没有该问题，则不需要发布分支（偶尔的热修复除外）。