扩展单个项目的多个项目的版本控制
我目前正在处理一系列项目，这些项目都是通用核心项目自己的特定分支/扩展，我正在寻找一种方法来管理项目协作的方式。
我理解以下内容有点模糊，我对版本控制只有一点经验，超出了单个项目的基本需求。我正在寻找的是是否有人以前遇到过类似的事情，如果是的话，他们是如何解决的？ （即使用了哪些技术/功能，还是只是创建良好实践的问题？）
我很幸运，可以完全放弃 SVN，并转向其他更合适的东西。
我们有
- 一个接收更新的核心颠覆源代码树（通用树）。
- 许多特定于域的 Subversion 源代码树将使用核心源代码树中的文件、修改现有文件并将新文件添加到核心源代码树中以生成最终产品。
我们的流程
- 核心源代码树中的更改被手动合并到特定于域的树中
- 有时，特定于域的树中的更改被视为“通用”/足够好，可以合并回核心树中（最终所有其他领域特定树）
我们想要的是一种（或多种）技术，可以
- 允许每个领域特定树针对核心树中的特定修订进行构建（即构建过程将获取特定核心）修订版，然后在其之上应用所有特定于域的更改以生成最终产品）
- 将允许每个特定于域的树更改要构建的核心的特定修订版（这可能会引入构建错误，但只要该过程更改相对简单且易于使用）。
- 为特定于域的树提供一种方法，将更改贡献回核心存储库。
- 由于通用核心树是开源的，但特定于域的树不是开源的，因此我们需要对最终解决方案的某些部分进行某种形式的访问控制。
预先感谢您的任何帮助。
I'm currently working with a collection of projects which are all their own specific branches / extensions of a generic core project and I am looking for a way to manage the way the projects collaborate.
I understand the following is a little vague, I only have a little experience with version control beyond the basic needs of a single project. What I am looking for is if anyone has come across something like this before and if so, how did they solve it? (ie what technologies/features were utilized or was it simply a matter of creating good practices?)
I'm in the fortunate position of being allowed to completely do away with SVN and move to something else if it is more appropriate.
We have
- A core subversion source tree (The generic tree) that receives updates.
- A number of domain specific subversion source trees that will use files from, modify existing files and add new files to the core source tree to generate a final product.
Our Process
- Changes in the core source tree are manually incorporated into the domain specific trees
- Occasionally changes in the domain specific trees are deemed “generic”/good enough to be incorporated back into the core tree (and eventually all other domain specific trees)
What we would like is a technology (or technologies) that can
- Allow each domain specific tree to build against a specific revision in the core tree (ie the build process would grab the specific core revision and then apply all the domain specific changes over the top of it to generate a final product)
- Would allow each domain specific tree to change the specific revision of the core to build against (This may introduce build errors but as long as the process of changing is relatively straightforward and easy to use).
- Provide a method for a domain specific tree to contribute changes back to the core repository.
- As the generic core tree is open source but the domain specific trees are NOT, we will need to have some form of access control placed on some parts of the final solution.
Thanks in advance for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会将它们视为版本控制系统中的单独项目。
然后使用 Ant 等构建系统来构建特定于域的项目。让构建脚本导出核心项目的特定修订版或标签，并将其放入特定于域的项目的目录中。 （该目录应该从版本控制中排除。）
或者您可以使用 svn:externals，这样每当您签出特定于域的项目时，SVN 都会自动签出核心项目的版本。
I would treat them as separate projects in your version control system.
Then use a build system like Ant to build the domain-specific projects. Have the build script export a particular revision or tag of the core project, and put it into a directory of your domain-specific project. (The directory should be excluded from version control.)
Or you can use svn:externals, so that SVN checks out o version of your core project automatically, whenever you check out a domain-specific project.