将 SVN 与登台和实时网站一起使用 [英] Using SVN With a Staging and Live Website

问题描述

我目前在托管的 Web 服务器上有一个 svn 存储库.我在本地工作，将我的更改提交到我服务器上的存储库，然后当我准备好实时推送更改时，通过 ssh 在我的实时文件夹中运行svn update".

I currently have an svn repository on my hosted web server. I work locally, commit my changes to the repository on my server, and then run an "svn update" via ssh in my live folder when I am ready to push the changes live.

我现在要添加一个临时站点，它将驻留在同一台服务器上.它只是同一台服务器上的另一个文件夹.

I am now adding a staging site, which will reside on the same server. It will simply be another folder on the same server.

问题是我将在临时服务器上对站点进行更大的更改，这可能需要长达一周的测试.在那段时间里，我可能想对不需要测试的实时站点进行小的外观更改.举个例子:

The issue is that I will be working on somewhat larger changes to the site on the staging server that may take up to a week of testing. During that time, I may want to make a small cosmetic change to the live site that requires no testing. Let's take an example:

1. 假设我的本地站点、临时站点和实时站点都从修订版 1 开始.
2. 我在本地进行重大更改、提交并更新我的临时服务器.Local 和 staging 处于修订版 2，live 仍在修订版 1.
3. 有人要求在实时网站上进行简单的文本更改.
4. 呃.现在我必须将我的本地副本恢复到修订版 1，进行小改动并提交.现在，我将实时站点更新到修订版 3，其中有一些细微的变化.
5. 我想继续处理我的主要更改，所以我将我的本地副本更新回修订版 2，并继续工作.
6. 等等......

这迫使我跟踪修订并不断更新和恢复.有没有更好的办法?我觉得我应该在这里使用分支和标签，但我不明白具体是如何使用的.

This forces me to keep track of revsions and constantly be updating and reverting. Is there a better way? I feel like I am supposed to be using branching and tags here, but I don't understand how exactly.

谢谢，约拿

推荐答案

我管理着一个由 5 名开发人员组成的开发商店.我们以下列方式在我们的网站上使用 SVN:

I manage a development shop consisting of 5 developers. We utilize SVN in the following way for our website:

• 在将作业标记为完成之前，开发人员将所有增强功能或错误修复提交到我们的开发"分支.
• 在 dev 分支中运行最新代码的暂存箱上测试作业.
• 一旦作业通过测试，该作业的修订就会合并到我们的主干分支.
• 我们的实时网络服务器运行主干分支.它们会定期通过发布"脚本进行更新，该脚本会更新实时服务器上的 SVN 并执行其他一些操作(例如混淆和最小化 CSS 和 JavaScript).

这允许小错误快速通过管道，而较大的作业可以根据需要花费尽可能多的时间进行开发和测试.

This allows small bugs to get through the pipeline quickly and larger jobs to take as much time as they need in development and testing.

由于每个开发人员都负责合并自己的工作，并且每次合并都包含一组较小的代码更改，因此它们进行得非常顺利.与让合并管理器为一组增强功能创建主要增强分支的旧模式相比，它要轻松得多.由于其他开发人员通常会在一组增强功能上协同工作，因此您最终会得到一个合并管理器，合并他们没有编写的代码，当您遇到合并冲突时，这会变得特别令人沮丧.

Since each developer is responsible for merging their own jobs and each merge consists of a smaller set of code changes, they go pretty smoothly. It is a lot less hectic than the older pattern of having a merge manager create a major enhancement branch for a set of enhancements. Since other developers typically work together on a set of enhancements, you would end up with a merge manager who merged code they didn't write, which becomes particularly frustrating when you have merge conflicts.

事实上，这种方法反映了 Git 和 Mercurial 等版本控制系统试图通过构建存储库的方式来推广的方法.使用这些版本控制系统，每个开发人员都有自己的本地"存储库.当他们想要从另一个存储库"进行更改时，他们必须将它们与本地代码合并，然后提交一个有效的合并"版本.

In fact, this method kind of mirrors the methods that versioning systems like Git and Mercurial attempt to promote by way of how they structure their repositories. With those versioning systems, each developer has their own 'local' repository. When they want changes from another 'repository', they have to merge them with their local code, then commit a valid 'merged' version.

您也可以使用安迪在他对这个问题的回答中提到的标记.它可能对您有用，但我更愿意将合并的责任交给编写代码的开发人员，而不是中央高级开发人员或发布经理.那样他们往往会更顺利.

You can also use tagging as Andy mentioned in his answer to this question. It may work for you, but I prefer to put the responsibility of merging on the developers who write the code rather than a central senior developer or publish manager. They tend to go more smoothly that way.

这篇关于将 SVN 与登台和实时网站一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！