1

我意识到 SVN 的目的是为应用程序或其他具有标准名称的目的存储结构化文件,并提交对这些文件的更新,成为修订。

我们知道 SVN 中的文件通常与环境无关。我将环境定义为 DEV、QA、UAT 和 PROD。假设我们将 QA 和 UAT“非结构化”文件混合到其中,并且想要跟踪 QA 脚本、QA 自动化脚本、屏幕截图、已修复缺陷的建议文档、开发的业务需求等等。本质上,我们想要一个地方来存储这些非结构化文件。我们将在下面的结构中存储这样的东西,还是不推荐这样做?

由于分支是较大项目(或应用程序)中较小的项目工作(或任务工作),因此我们将开发部分存储在分支子文件夹中。Trunk 是生产中产品的稳定版本,对吧?过去,我听说标签是部署和回滚脚本应该存在的地方,在过去的某个时间点,或多或少是静态的。所以我想我们要么把这些非结构化文件放在分支或标签中。

我说“非结构化”的原因是因为我们可能有 QA 屏幕截图,这些截图可能因每个开发部分而不同,并且可能在以后变得过时。我们显然不想在开发后将这些重新检入主干,但在开发过程中,屏幕截图可能会发生变化,因为新的开发更改在该分支实际上稳定之前被检入分支,因此我们可能希望用覆盖该屏幕截图较新的屏幕截图。此外,测试脚本会随着开发的变化而变化。我们还有开发的业务需求、DEV和QA的测试计划、DEV和QA的测试结果、开发前发现的缺陷描述、缺陷开发修复描述等……

这是我们目前拥有的结构:

\app
\app\trunk\
\app\trunk\file_x
\app\branches\
\app\branches\YYYY-MM-DD_branch_x\file_x
\app\tags\
4

1 回答 1

2

文档的文件和测试非常适合作为 repo 中单独树的内容(与 app-sources 或外部共享,使用 svn:externals 链接到 app-repo)。存储库可能类似于

/trunk
/tests
/docs

结果

其他 QA 工作(bug-hunting)是(一些、任何、首选)问题跟踪系统的主题:发现的错误被添加到其中(带有描述、重现步骤、屏幕截图),可以在工单的评论中讨论,与错误提交有关(也从票证链接)

于 2013-08-08T14:17:37.690 回答