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