我们如何改进SVN的使用？

Question

我差不多两年前开始从事新工作，SVN存储库流程已经存在。这个过程就是这样的，因为从来没有太多考虑过利用SVN来管理代码库的最佳前瞻性方法。现在我们处于这样一种情况：我们需要在增长之前做出改变。 我们正在寻找一种更好的方式来使用适合我们需求的SVN。

• 我们有一个基本框架，我们所有的客户端代码都位于其上 在一个存储库中管理。
• 我们还有一个存储库 我们管理所有自定义perl模块和我们的存储库 管理基础框架的所有皮肤。
• 然后我们为每个客户的业务部门提供了存储库。

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

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

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

以我们的方式管理SVN是完全没有效率和负担，因为通常会有错过的文件对于修复/更改是必不可少的，当涉及到将代码合并到主干时我们没有使用SVN分支/合并，这对我们的看门人来说是更多的工作。我们的流程中有很多开销，如果我们能够弄清楚如何利用SVN的方式，可以在这里消除。

我来Stack Overflow因为我非常尊重这里的格式和社区。非常感谢任何建议！

Answer 1

如果您清楚地区分源代码和已安装的程序，您的工作流程将会有很大改进。代码应从源位置（没有生产相关性）流向安装位置，如：

http://your-svn-server

       | checkout
       v

/home/local-checkout

       | make install
       v

/var/www   /opt   /usr

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

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