我们有 3 个 Web 服务器，处于开发的不同阶段：
Development
Testing
Production
这是镜像存储库，与更通用的 Trunk/Branch/Tag 模式不同。我开发了一个提交后挂钩，用于自动将提交推送到存储库服务器上的发布文件夹，然后将该文件夹与远程开发服务器 webroot 进行 rsync。
就这个问题而言，测试和生产可以被认为是做同一件事。
为了使事情变得更加复杂，每个项目都有 3 个文件夹，其中可能包含以下材料：
coderoot
www
wwws
我当前的存储库布局是
dev (trunk)
-coderoot
-www
-wwws
testing (branch)
-coderoot
-www
-wwws
production (tag)
-coderoot
-www
-wwws
每个项目存储库都具有此布局。是否可以将 9 个子文件夹中的每一个作为单独的分支进行版本控制？对于任何具有一些 subversion 经验的人来说，这种方法是否合理（使用 TortoiseSVN 作为客户端）？
我是这方面的新手，所以我愿意听取大家的意见。我希望每个子文件夹都有自己的版本控制时间线，但我意识到如果没有 9 个文件夹中的每一个的存储库，这可能是不可能的，这会使在 Tortoise 中浏览结构变得不那么方便。
我对于这个问题的主观性表示抱歉，但我不知道在哪里还可以得到明智的观点。
答案1
嗯，你绝对正确，这个问题是主观的，但最好不要做你上面想的事情。分支的设计和使用主要是为了许多不同的开发人员可以在项目的不同部分工作，但当代码合并在最后完成以接近上线或准备等时，所有这些都需要再次完美同步。当应用程序准备发布时。根据我的经验，你上面的建议会让跟踪每个文件夹的变化成为一场噩梦，因为它们将是具有自己的提交、修订和日志等的独特分支。将它们各自变成一个存储库也会使事情变得更加复杂。标签、分支和树干的概念来自树的结构，每个分支都可以服务于一个独特的目的，并支持较小的鸟（初级开发人员）可以在较小的树枝上筑巢，而鹰可以栖息在树冠上更高更重要的树枝（经验丰富的开发人员）上。没有一个分支与树是分开的，所有分支都需要能够重新追踪并将代码合并回树干。
标签是发布的快照，最好是最新主干的快照。你设置的是坏习惯。我上次在大型软件公司工作已经有一段时间了，但我上次工作的赌博组织几乎把所有的存储库都设置成了那样。
1 代表 = 1 项目。n 分支数 = n 开发人员数。n 标签数 = n 从分支或主干发布的版本数。
可以从开发人员签入并希望尽快在测试区域进行测试的小型版本中创建标签。当应用程序接近完成时，当代码准备好在暂存或测试环境中进行测试时，也可以从主干中创建标签。
我的知识有限，但从我在前雇主那里看到的情况来看，这是最好的做事方式。请理解，我不是在对你高高在上或居高临下，这篇文章的语气也无意描绘前者或后者。我只是想就很久以前做过的事情进行一番思考。