5

大约两年前，我开始了一份新工作，SVN 存储库流程已经存在。这个过程之所以如此，是因为从来没有人考虑过利用 SVN 管理代码库的最佳前瞻性方式。现在我们处于需要做出改变的情况下，我们才能成长得更多。我们正在寻找一种更好的方式来使用适合我们需求的 SVN。

  • 我们有一个基础框架，我们所有的客户端代码都位于该框架之上，并在一个存储库中进行管理。
  • 我们还有一个存储库，用于管理所有自定义 perl 模块，以及一个存储库，用于管理基础框架的所有皮肤。
  • 然后，我们为每个客户的业务部门建立了存储库。

所有这些存储库中都有代码，这些代码有时在 /var/www、/usr/local、/opt 目录及其子目录中重叠。

到目前为止，我们已经通过在服务器的工作区域（/var/www、/opt、/usr）中进行更改来管理此问题，然后将所有更改及其目录结构移到我们主目录中的工作副本中我们可以对这些文件执行 svn 操作。

我已经做了一些实验来检查服务器根目录上的存储库，但是我必须 sudo 我所有的 svn 操作。另一个问题是，如果我切换到 repository-for-customer-a 并且我必须对基本框架进行更改，那么这些更改是否会被跟踪？它们会包含在 repository-for-customer-a 的 svn stat 中吗？或者，如果我进行 SVN 提交，服务器是否会同时将文件提交到两个存储库？

以我们的方式管理 SVN 完全是低效的，而且是一种责任，因为经常会丢失对修复/更改至关重要的文件，并且在将代码合并回主干时，我们没有使用 SVN 分支/合并，因此我们的看门人需要做更多的工作。我们的流程中有很多开销，如果我们能弄清楚如何按照它的预期使用方式来利用 SVN，就可以在这里消除这些开销。

我来到 Stack Overflow 是因为我非常尊重这里的格式和社区。任何意见是极大的赞赏！

4

1 回答 1

1

如果您清楚地区分源代码和已安装的程序，您的工作流程将大大改善。代码应从源位置（与生产无关）流向安装位置，如下所示：

http://your-svn-server

       | checkout
       v

/home/local-checkout

       | make install
       v

/var/www   /opt   /usr

确保代码永远不会在此层次结构中向上移动，除非通过svn commit. 特别是，不要猴子补丁 /var/www 然后将文件复制到您的签出目录中。您永远不会复制所有相关更改。

这听起来像是很多工作，但事实并非如此。make install脚本通常需要很少的时间来运行，尤其是在不涉及编译器的情况下。从好的方面来说，当您想迁移到不同的机器或只是在新机器上安装任何东西时，定义的部署过程可以极大地帮助您。

于 2013-02-14T15:45:17.820 回答