可配置软件的分支策略
我正在开发一个为各种客户群体生成的应用程序。根据客户的不同，软件的用户界面元素可能会有所不同。例如，一个客户可能需要菜单项 X，而另一个客户则需要菜单项 Y。
目前，用户界面的所有配置都是通过 XML 完成的（其中大部分使用 spring）。对于不同的菜单选项示例，一个 XML 文件可能具有要在 UI 上显示的菜单选项列表。
我试图弄清楚如何最好地管理软件的分支，以便它们都可以使用相同的核心基线，并且都可以接收错误修复、更新等。分支之间唯一不同的是 XML配置文件。
是否有管理此问题的良好实践/技术？我不完全确定每个客户需要不同的分支机构 - 这只是我的第一个想法，所以我愿意接受其他建议。但任何关于如何最好地设置它的帮助将不胜感激。
如果有帮助的话，我们没有在这个项目中使用分布式版本控制系统（使用 SVN）。
谢谢，
杰夫
I'm working on an application which is produced for various sets of customers. Depending on the customer, the software's user interface elements may vary. For example, one customer might need menu item X, while the another customer gets menu item Y.
Currently all of the configuration for the user interface is done via XML (much of it with spring). For the different menu options example, one XML file might have a list of menu options to display on the UI.
I'm trying to figure out how to best manage the branching of the software such that they can all use the same core baseline, and all receive bug fixes, updates, etc. The only thing that will be different between the branches is the XML configuration files.
Are there good practices/techniques for managing this? I'm not entirely sure that each customer needs different branches - that was just my first thought, so I'm open to other suggestions. But any help with how to best set this up would be appreciated.
If it helps to know, we are not using a distributed version control system for this project (using SVN).
thanks,
Jeff
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您可以管理它，我强烈建议不要为每个客户开设一个分支机构。只需考虑一下合并开销，乘以由于其他原因（例如发布后修补）而可能拥有的正常分支数量。
如果您可以坚持使用配置方法（无需重新编译即可打开和关闭功能），我希望您会发现这是一种更容易维护的方法。
If you can manage it I would strongly advise against one branch per customer. Just think of the merging overhead, multiplied by the normal number of branches you might have for other reasons such as post-release patching.
If you can instead stick with the configuration approach -- turning features on and off without recompilation -- I expect you will find that a much easier approach to maintain.
在主干中，我将维护几个以客户端命名的配置文件。在准备交付时，我只会复制相关的配置文件，并按软件的预期重命名。
In the trunk, I would maintain several configuration files, named after the client. When preparing a delivery, I would copy only the relevant configuration file, renamed as expected by the software.
如果客户之间唯一真正不同的是 XML 配置文件，那么我不会为每个客户创建完整的代码分支。这是 DRY 的一个应用——如果你的代码在两个地方重复，那么它就会不同步。
在这种情况下，您可以将所有配置文件保留在单独的分支中，或者使用基本文件并为每个客户提供配置覆盖。然后，您只需要制定一个构建流程，可以为给定的客户将所有内容组合在一起。
我知道这都是主观的，但这就是我处理问题的方式。
If the only thing that will really be different between customers are the XML configuration files, then I would not create a full code branch for each customer. It's an application of DRY - if you have the code repeated in two places, then it will get out-of-sync.
In that case, you could just keep all of the configuration files in separate branches, or use a base file and supply configuration overrides per customer. Then you would just need to make a build process that could put it all together for a given customer.
All subjective I know, but that's how I would approach the problem.