源代码管理相关性的最佳实践

问题描述：

如何处理依赖于独立框架或库的非编译项目的源代码管理设置？例如，项目A使用框架B.项目A是否也包含来自框架B的代码在其存储库中？有没有办法从不同的仓库自动包含它，或者我需要手动更新它吗？这种情况通常采取什么方法？假定我控制了项目A和框架B的存储库，并且两者的源代码都未编译。源代码管理相关性的最佳实践

任何资源或建议将不胜感激。我目前正在使用Subversion（在一个非常基础的层面上），但我想切换到Mercurial，以便我可以用Fogbugz来试用Kiln。

编辑：在Mercurial中，你会使用这个函数的父库吗？

这似乎是一个近乎完美的重复问题，只是昨天问：http://stackoverflow.com/questions/2392404/dvcs-how-structure-with-large-integrated-code-base-with-multiple-projects-sharin – 2010-03-08 00:07:37

答

如果您想使用Subversion并需要包含来自其他存储库的代码，则Subversion Externals可能是一个选项。

但是，如果您正在处理可编译的代码，那么建立一个只需获取所需二进制文件的构建过程可能会更好。像Maven这样的构建工具可以帮助你。

或常春藤（http://ant.apache.org/ivy/）Apache依赖管理器。但是Maven和Ivy都可能只适用于Java项目。我不知道有人曾经在C/C++环境中使用过它们。（？） – 2010-03-09 14:13:51

我们专门为此使用了外部。代码取决于模块的修订版本X.当代码检出时，外部将该修订拉入树中。使依赖显而易见。 – 2010-04-02 13:32:14

答

大部分时间我都试图包含在Subversion中构建项目所需的一切。这是使用C＃和Visual Studio，所以我的大部分依赖是dll。在其他环境中，约定可能会有所不同。

这通常是我如何布置一个新项目：

裁判
- SomeOpenSourceProject.dll
- SomePurchasedComponent.dll
MyProjectA
- MyProjectA。 CSPRO Ĵ（引用.. \ REF \ SomeOpenSourceProject.dll）
MyProjectB
MyWeb即可（引用.. \ REF \ SomePurchasedComponent.dll）
MyApplication.sln

这样一来，它可以被一个新的开发者检查出来并且没有太多麻烦。过去他们曾经为dll使用网络共享，但是由于不同的项目使用了不同的版本，所以很烦人，如果你想回到颠覆或分支或其他任何东西，很难跟踪。这个结构很好地解决了这些问题。

答

如果B是一个开源项目，并且您想用A编译它，我建议您尝试vendor drop技术。这样你可以保留你自己的补丁。

如果B是您公司的专有代码，并且您不想编译它，那么只需将编译的二进制文件复制到A'repo中就可以了。

答

我做的非常相似，大卫·霍格的东西，但它看起来像这样：

- lib (anything used IN the software) 
    - purchased_component.dll 
    - internal_library.dll 
    - icon_set 
     - icon1.ico... 
- tools (anything used to BUILD the software) 
    - nunit.framework.dll 
    - settings.stylecop 
    - settings.fxcop 
- src (the software itself) 
    - myapp.sln

大部分的灵感，对于这种设置，从tree surgeon出来（相当过时现在虽然）

我也使用过这种方法。我喜欢将依赖关系分解为发布版（lib）附带的那些东西，而不是开发人员构建/文本/分析解决方案（工具）所需的东西。 .NET书中优秀的Brownfield应用程序开发推荐了相同的方法。 – dthrasher 2011-10-07 15:45:16

源代码管理相关性的最佳实践

相关推荐