生产环境上有很多个版本的商城产品，可能存在以下几种情况：
1、由于授权和商务等一系列的原因，可能有些有1.0、2.0、3.0...这样的版本，而这每个版本都定制了很多功能，加入一些特定用户要求的特定需求，但是唯一相同的是主体的下单流程。
2、上面这些版本的系统都是出自同一个主体相同的综合商城，每次综合商城的功能是最全且bug最积极的修复。
3、主体的产品商城修复的某些bug，比如下单流程的小bug修复了，那么依托于主体产品定制开发的每个小商城都必须全部手动更新。
4、也有可能，下面的某个小商城在定制开发的途中发现了某个bug，而主体产品商城没有更新，需要一起同步更新到主体产品商城。
5、当主体的商城产品要从v1升级到v2时，下面某个小商城也要一起升级时，小商城有定制的部分但是要更新到v2。
有以下几种方案：
1、每个定制开发的小商城全部独立一套代码进行开发部署
2、主体升级功能或修改bug时或者下面的更新了某个bug要同步到主体时：
①使用Beyond Compare 文件比对工具比对，但是需要消耗大量的人力和位置的文件；
②使用svn的分支功能进行同步，目前是最优的办法，结构清晰，有版本进行对比，且能批量版本进行同步【推荐】
3、在每个小商城上的代码更目录都标注是从那个主体商城迁移开发的，包括升级了之后，都要简要标明，有助于以后的代码更新和svn分支合并。
和discuz这种大型产品的区别：
1、其实discuz这种大型产品是一整套一成不变的功能，无论是A客户还是B客户，用的功能已经定死，只能官方说升才能升，其余的一律不修改。所以可以打包成安装文件进行安装，而无需使用每个客户一套代码进行开发。
2、商城的定制开发对于我们来说是必须的，A客户可能需要短信验证加特殊说明等，B客户喜欢从头改到脚，如果打包成安装文件那么意味着人工去修改特定的页面屏蔽某些功能，每次修改玩主体产品商城时，都要根据每个客户不同的授权进行功能的屏蔽。如果是几个客户还可以这样做，但是10几个的时候，到20几个时候那么就很痛苦了！
3、所以，最后总结出定制需求修改的产品，全部一套代码进行开发，采用svn的分支进行功能合并和代码bug的修复（双向）。