在工作中，我们正在从无 SCM 转向 Mercurial。这有点学习曲线，但在搞砸了两天之后，我肯定觉得它更舒服了。
我仍然有一个未解决的大问题：一旦代码完成，我们如何处理实际部署？
我们是否应该在生产（实时）服务器上运行 Mercurial 的副本？或者我们应该设置 rsync 或其他东西来从 repo 同步到 web 目录？这里的最佳做法是什么？
如果我们只是将 apache 指向 repo，我认为这没问题，只要我们小心不要指向hg update不同的、不稳定的分支？不过，这对我来说似乎还是有点危险。有没有办法强制它只切换到某些版本？
还是将 apache 指向 repo 只是一个糟糕的主意，而我应该做其他事情？
在一个相关主题上，我还听到一些关于将任何升级脚本（例如 MySQL 的架构更改）置于版本控制之下的讨论，以便在部署版本时可以运行它们。但这将如何作为工作流程的一部分工作呢？我不想保留它和其他所有东西，因为它是一个临时的一次性使用脚本......
感谢你们提供的任何建议。
我最近发现了这个hg archive命令，所以我想我们会用这个来代替。我编写了一个 bash 脚本，该脚本更改为“生产”分支的头部，然后将其存档到预定的目的地。似乎工作。
我仍然很感激你们对这是否是一个好主意的任何反馈。
我认为将 apache 指向 repo 绝对是一个坏主意，如果您只想拍摄开发文件的快照，hg 存档就可以了。
我发现我的开发源文件和部署的应用程序（即使对于不需要编译的 Web 应用程序）通常非常不同，后者是从前者的子集派生的。
我倾向于使用 shell 脚本甚至 Makefile 在开发目录的子目录中“构建”已部署的应用程序，这可能只是创建目录树并复制必要的文件或可能包括压缩脚本等。
这样，您必须有意识地决定是否在部署的版本中包含文件，从而有助于防止将开发实用程序文件意外地留在可能导致安全风险的在线应用程序中。
变化无常的唯一部分是，对于一个主要版本，我创建了一个新的命名分支（例如：1.5），在默认分支上继续开发。如果需要，可以将后续的错误修复或补丁移植到发布分支，如果发布了错误修复发布，我会用新版本（例如：1.5.1）标记发布分支。