我目前正在使用subversion来管理我的源代码，而且我已经到了需要为我正在为客户工作的软件品牌的地步。所有品牌都在项目资源中处理，因此更改客户端的外观非常简单。我遇到的问题是在源存储库中维护软件的品牌版本。现在它是一个单独的分支，但是当尝试将更改从trunk合并到品牌分支时，它会愉快地覆盖品牌资源文件。
什么是维护这些差异的好方法，但仍然能够轻松地检查为构建中继版本或使用自定义资源文件构建版本所需的所有内容？
答案 0 :(得分：1)
您可以将品牌重新发布作为一个单独的回购，使用香草分支作为外部。
另一种方法是将所有内容保存在一个分支中，让构建过程完成选择要使用的特定品牌文件的工作。
答案 1 :(得分：1)
你需要将品牌作为核心技术的包装，这就是我所知道的每一个项目都是如此。
但是，如果你从一开始就没有想到这样的项目，你可能需要一两个星期来重构一切。
理想情况下，您不应该需要分支，但无论如何，只要有合理的工程原理并保护客户端的代码稳定性，这是一个好主意。如上所述，品牌推广应该是可以在编译时或运行时使用某种包装完成的。
答案 2 :(得分：0)
品牌推广应该是顶级项目，项目的核心部分作为子项（或依赖于项目继承模型的依赖项）。在subversion中，您可以使用externals将核心产品源代码包含在顶级产品中，或者您可以构建核心产品并使用顶级项目来创建最终的“程序集”。
答案 3 :(得分：0)
那么，您可以使用合并集，只需合并一系列提交，或者您可以将品牌资源文件保存在分支根目录的单独目录中？然后在合并时，只需选择根目录中的目录，不包括品牌名称。
我喜欢合并一系列提交，因为这样可以避免在分支上吹掉新的工作。但是如果需要合并所有内容，可以将项目移动到子目录（例如：“Source”），将品牌移动到第二个子目录。然后在Eclipse或其他任何你可以选择从trunk / source合并到branch / source。
e.g：
此：
/ SVN /凸出/中继/一个
/ SVN /凸出/中继线/ B
/ SVN /凸出/中继线/ C
/ SVN /凸出/中继/ d / E / F /品牌
成为这个：
/ SVN /凸出/中继/源极/一个
/ SVN /凸出/中继/源/ B
/ SVN /凸出/中继/源/ C
/ SVN /凸出/分支/品牌
/ SVN /凸出/分支/源极/一个
/ SVN /凸出/分支/源/ B
/ SVN /凸出/分支/源/ C