代码之家 › 专栏 › 技术社区 › VirtuosiMedia

源代码管理依赖项的最佳实践

dependencies mercurial version-control svn

VirtuosiMedia · 技术社区 · 15 年前

如何处理的源代码管理设置 非编译 依赖于单独框架或库的项目?例如,项目A使用框架B。项目A是否也应该将框架B中的代码包含在其存储库中?是否有一种方法可以从不同的存储库中自动包含它,或者我必须手动更新它?对于这种情况,通常采用什么一般方法?假设我同时控制项目A和框架B的存储库,并且没有编译两者的源代码。

如有任何资源或建议,将不胜感激。我目前正在使用Subversion(在一个非常基本的级别上),但是我想切换到Mercurial,这样我就可以用FogBugz试用一下Kirne了。

编辑:在Mercurial中,您会为这个函数使用父存储库吗?

4 回复 | 直到 15 年前

Josef Pfleger 15 年前

如果您想使用Subversion,并且需要包含来自不同存储库的代码, Subversion Externals 可能是一种选择。

但是,如果您处理的是可编译代码,那么最好设置一个只获取所需二进制文件的构建过程。构建类似的工具 Maven 可以帮到你。

David Hogue 15 年前

大多数时候,我试图把所有必要的东西都纳入到颠覆性的项目中。这是使用C和Visual Studio,因此我的大多数依赖项都是DLL。在其他环境中,约定可能会有所不同。

这通常是我布置新项目的方式:

裁判
- someopensourceproject.dll文件
- somepurchasedcomponent.dll文件
MyPrimeCuta
- 我的项目A.csproj (引用..\ref\someopensourceproject.dll)
MyPrimeStub
我的网页 (引用..\ref\somepurchasedcomponent.dll)
我的应用程序.sln

这样,新开发人员就可以轻松地签出和构建它。在过去,他们使用的是DLL的网络共享,但是由于不同的项目使用了不同的版本,这会让人恼火,如果你想回到Subversion或Branch或其他地方,就很难跟踪到。这个结构很好地解决了这些问题。

Steven Evers 15 年前

我做了一些和大卫霍格非常相似的事情,只是看起来像这样:

- 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 (不过现在已经相当过时了)

bo bo 15 年前

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

如果B是您公司的专有代码,而您不想编译它,那么只需将编译后的二进制文件复制到“repo”中就容易多了。