使用SVN与暂存和实时网站

Jon*_*nah 9 svn

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

我现在正在添加一个暂存站点,它将驻留在同一台服务器上.它只是同一台服务器上的另一个文件夹.

问题是我将在登台服务器上对网站进行稍微更大的更改,这可能需要长达一周的测试时间.在此期间,我可能希望对不需要测试的实时网站进行小的修饰.我们来举个例子:

  1. 假设我的本地,登台和现场网站都从修订版1开始.
  2. 我在本地进行重大更改,提交它们,并更新我的登台服务器.本地和分期是修订版2,实时仍然是1.
  3. 有人要求在网站上进行简单的文字更改.
  4. 啊.现在我必须将本地副本还原为修订版1,进行小改动并提交.现在我更新到实时站点到版本3,它有一个小的变化.
  5. 我想继续处理我的主要更改,因此我将本地副本更新回修订版2,并继续工作.
  6. 等等....

这迫使我跟踪转速并不断更新和恢复.有没有更好的办法?我觉得我应该在这里使用分支和标签,但我不明白究竟是怎么回事.

谢谢,约拿

Sha*_*aun 9

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

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

这允许小错误快速通过管道和更大的作业,以便在开发和测试中花费尽可能多的时间.

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

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

您也可以使用Andy在他对这个问题的回答中提到的标记.它可能适合您,但我更愿意将合并的责任放在编写代码而不是中央高级开发人员或发布经理的开发人员身上.他们往往更顺利地走这条路.