我们目前正在使用没有Trunk / Branches / Tags结构的SVN。到目前为止，我们对它很好，但现在，我们已达到一个水平，我们需要某种系统，可以处理3个不同服务器的3个不同级别的版本。
目前这就是我们一直在做的事情：
单个存储库中的所有文件，一旦完成工作，数据将提交给我们的开发服务器，在测试之后，它将被移动到登台服务器，经过另一轮测试后，它将被移动到实时服务器。 / p>
但在上述过程中，我们很少有空间处理新功能并同时修复小问题。因此，为了解决这个问题，我想，我们可以使用Trunk / Branches / Tags结构，其中最新的开发版本可以存储在Trunk中并部署在我们的开发服务器上。
标签可以包含登台服务器的版本（例如1.0.1,1.0.2等..），而Branches将拥有Live服务器的最新版本（例如1.0,1.1等..）。
现在，问题是，目前所有的开发都是在本地服务器上完成的，我不知道如何在单个服务器上运行此结构，所有开发人员都可以在单个根文件夹中工作。
或者我们应该制作3个单独的根文件夹（开发，暂存和实时）？
欢迎提出任何建议。
答案 0 :(得分：1)
我们的流程在部署服务器上包含三个文件夹（虽然我们有时会将这三个文件夹分成三个不同的服务器）：/ dev，/ test和/（对于prod）。
在存储库中，我们处理主干中的新功能。对trunk的更改会自动推送到/ dev文件夹，以便我们可以实时查看该站点的外观。
在预定义的截止日期，我们分支中继并将其命名为test，并将测试分支导出到/ test。我们继续在trunk中开发新功能，同时修复测试分支中的错误，将每个错误导出到服务器上的各自文件夹，然后继续测试/ test文件夹。
一旦我们对测试感到满意，我们就会用公共版本号（如1.2）标记它。然后我们将该标记部署到/（生产文件夹）。然后我们将测试分支的更改合并到主干中，以便我们的错误修复得到合并。然后我们开始下一个周期。
答案 1 :(得分：0)
您的存储库结构应独立于您的部署;也就是说，它应该没有引用staging，live或任何与代码部署后的位置有关的内容。
您描述版本号系统的方式，它们都是标签。请查看branching and merging chapter of the SVN documentation以获取解释。