大约两年前,我开始了一份新工作,SVN 存储库流程已经存在。这个过程之所以如此,是因为从来没有人考虑过利用 SVN 来管理代码库的最佳前瞻性方法。现在我们处于一种情况,在我们成长得更多之前,我们需要做出改变。我们正在寻找一种更好的方式来使用适合我们需要的 SVN。
所有这些存储库中的代码有时会在 /var/www、/usr/local、/opt 目录及其子目录中重叠。
到目前为止,我们已经通过在服务器的工作区域(/var/www、/opt、/usr)中进行更改,然后将所有更改及其目录结构移动到主目录中的工作副本来管理此问题我们可以对这些文件执行我们的 svn 操作。
我已经做了一些试验,通过服务器的根目录检查存储库,但随后我必须对我所有的 svn 操作进行 sudo。另一个问题是,如果我切换到针对客户的存储库并且我必须对基础框架进行更改,那么是否会跟踪这些更改?它们会包含在 repository-for-customer-a 的 svn stat 中吗?或者,如果我执行 SVN 提交,服务器会同时将文件提交到两个存储库吗?
以我们的方式管理 SVN 是完全低效的,而且是一种负担,因为经常会丢失对修复/更改至关重要的文件,并且在将代码合并回主干时,我们没有使用 SVN 分支/合并,所以我们的看门人需要做更多的工作。我们的流程中有很多开销,如果我们能弄清楚如何以预期的方式利用 SVN,就可以在这里消除这些开销。
我来到 Stack Overflow 是因为我非常尊重这里的格式和社区。任何意见是极大的赞赏!
如果您清楚地区分源代码和已安装的程序,您的工作流程将会大大改善。代码应从源位置(与生产无关)流向安装位置,如下所示:
http://your-svn-server
| checkout
v
/home/local-checkout
| make install
v
/var/www /opt /usr
Run Code Online (Sandbox Code Playgroud)
确保代码永远不会在此层次结构中向上移动,除非通过svn commit. 特别是,不要对 /var/www 打猴子补丁,然后将文件复制到签出目录中。您永远不会复制所有相关的更改。
这听起来工作量很大,但事实并非如此。脚本make install通常只需要很少的时间来运行,尤其是在不涉及编译器的情况下。从好的方面来说,当您将来想要迁移到不同的机器或只是在新机器上安装任何东西时,定义的部署过程可以为您提供很大帮助。