大型PHP企业内部Web系统版本控制系统选型咨询（含权限控制需求）

首先，结合你提到的中央唯一版本、文件夹级权限控制、协作开发、分支/推送支持这些核心需求，我整理了几个适配的方案，涵盖你关注的Mercurial以及其他更贴合场景的选项：

一、Subversion（SVN）：原生中央式+细粒度权限，直接匹配需求 #

SVN本身就是为中央式版本控制设计的，完美符合你“唯一最新版本”的要求，而且原生支持文件夹级别的权限控制，不需要额外复杂扩展：

• 权限配置：在服务端的authz文件里可以精确到单个文件夹的读写权限，比如给自由开发者只开放/trunk/modules/payment/的读写权限，其他路径完全不可访问，从根源上避免他们获取整个系统代码。
• 协作与分支：支持创建开发分支，开发者在分支上修改后提交到中央仓库，经过审核再合并到主分支；推送（commit后同步到中央）是原生功能，完全解决你当前没有推送和分支的问题。
• 兼容现有系统：SVN的代码结构和你当前服务器文件结构可以完全对齐，现有更新系统可以直接对比SVN主分支代码和生产环境的差异，Web编程环境修改文件后也能直接提交到SVN的开发分支，保留撤销和diff功能。

二、Git + Gitolite：强大生态+精细权限控制，兼顾灵活性 #

虽然Git默认是分布式，但可以通过工具配置成严格的中央仓库模式，同时解决权限问题：

• 权限控制：用Gitolite这个自托管的Git权限管理工具，能实现路径级别的权限控制——你可以给自由开发者设置只能读写指定模块的文件夹（比如src/order-module/），其他路径禁止访问。配合Git的稀疏检出功能，他们拉取仓库时只会下载有权限的部分文件，不会拿到整个系统代码。
• 分支与协作：Git的分支模型非常成熟，支持创建feature分支、开发分支，开发者推送到中央仓库的分支后，通过合并请求（MR）审核代码再合并到主分支，确保生产分支的稳定性。
• PHP环境兼容：Git对PHP代码完全友好，不需要额外适配，现有更新系统可以基于Git的版本差异来应用变更。

三、Mercurial + ACL扩展：你关注的方案，适配中央式需求 #

Mercurial确实可以配置成中央仓库模式，同时通过扩展实现权限控制：

• 中央仓库配置：可以设置中央仓库为唯一权威版本，禁止开发者直接合并到主分支，必须推送到开发分支等待审核合并。
• 权限控制：借助Mercurial的acl扩展或者第三方的hg-acl工具，能设置用户对特定路径的访问权限。再结合Mercurial的稀疏克隆/检出功能，让自由开发者只获取他们有权限的模块文件。
• 分支支持：Mercurial支持分支和推送功能，能解决你当前无法分支开发的问题，不过它的生态和工具链相比Git要弱一些。

四、与现有系统集成的建议 #

不管选哪个版本控制系统，都可以和你现有的工具无缝对接：

• 把版本控制的主分支作为生产就绪代码源，现有更新系统对比主分支代码和生产环境的文件/数据库差异，批量应用变更。
• Web编程环境修改服务器文件后，直接提交到版本控制系统的开发分支，这样既保留了原有的撤销和diff能力，又能利用版本控制的分支和推送功能管理变更。

选型建议 #

• 如果追求最简单的配置和原生中央式体验，优先选SVN，它的权限控制不需要额外折腾，直接满足你的核心需求。
• 如果想要更灵活的分支模型和强大的工具生态，选Git+Gitolite，适合长期的多开发者协作场景。
• 如果已经熟悉Mercurial，想要沿用现有知识，那Mercurial+ACL扩展也是可行的选项。

最后，别忘了配合保密协议对自由开发者进行约束，技术手段+合同保障双重降低代码泄露风险。

内容的提问来源于stack exchange，提问作者Misterr Moron