source dependencies (you need to include, within the sources of your project, source from another project),
binary dependencies (you need to include a packaged set of files, like the ones found in a shared library).
If, when you say "I use these libraries in a project", you mean you need the binaries in order for your project to compile, then you could store said binaries in an external repository (i.e. not a (D)VCS like Mercurial, but an artifact repository like Nexus)
But if you mean you need to include sources, because you are also making some evolutions to those libraries while using them to develop your project, then Mercurial subrepos are a better fit.
In my own experience, maintaining compatibility with libraries that you are writing simultaneously is drastically improved by using export maps to provide multiple versions of your interfaces to client programs. The best guide I know of is Ulrich Drepper's http://people.redhat.com/drepper/dsohowto.pdf
If the libraries are under your source control, life should be easy. What I tend to do is the same as I do for different versions of third party libraries: Have different folders for different versions.
The third party library folder structure looks like this:
Each and every project defines it dependencies on specific versions of each library. Reverting back to an old version of a project, thus also reverts the dependency to older versions of the library(ies).
Now with third party libraries you generally don't have as many different versions as you can do with your own libraries, but the same principals apply. And to aid in "current development" - where you don't have a particular version number yet, you could simply have a "head" version. Then when you "release" a version of your library, just add that version's folder and adjust the project definitions that have up till know used the "head" because of parallel development, to depend on the new version number...
发布评论
评论（3）
您有两种主要的依赖关系：
如果，当您说“我在项目中使用这些库”时，您的意思是您需要二进制文件才能编译项目，那么您可以将所述二进制文件存储在外部存储库中（即不是像 Mercurial 这样的 (D)VCS，但是 像 Nexus 这样的工件存储库）
但是，如果您的意思是需要包含源代码，因为您在使用这些库来开发项目时也对这些库进行了一些改进，那么 Mercurial subrepos 更适合。
You have two main kind of dependencies:
If, when you say "I use these libraries in a project", you mean you need the binaries in order for your project to compile, then you could store said binaries in an external repository (i.e. not a (D)VCS like Mercurial, but an artifact repository like Nexus)
But if you mean you need to include sources, because you are also making some evolutions to those libraries while using them to develop your project, then Mercurial subrepos are a better fit.
根据我自己的经验，通过使用导出映射向客户端程序提供多个版本的接口，可以大大提高与同时编写的库的兼容性。我所知道的最好的指南是 Ulrich Drepper 的 http://people.redhat.com/drepper/dsohowto .pdf
In my own experience, maintaining compatibility with libraries that you are writing simultaneously is drastically improved by using export maps to provide multiple versions of your interfaces to client programs. The best guide I know of is Ulrich Drepper's http://people.redhat.com/drepper/dsohowto.pdf
如果这些库在您的源代码控制之下，那么生活应该很容易。我倾向于做的事情与我对不同版本的第三方库所做的相同：为不同版本设置不同的文件夹。
第三方库文件夹结构如下所示：
每个项目都定义了对每个库的特定版本的依赖关系。恢复到项目的旧版本，因此也会恢复对库的旧版本的依赖关系。
现在，对于第三方库，您通常不会像使用自己的库那样拥有那么多不同的版本，但适用相同的原则。为了帮助“当前开发”——如果您还没有特定的版本号，您可以简单地拥有一个“头”版本。然后，当您“发布”库的一个版本时，只需添加该版本的文件夹并调整项目定义，直到知道由于并行开发而使用“头”，以依赖于新版本号......
If the libraries are under your source control, life should be easy. What I tend to do is the same as I do for different versions of third party libraries: Have different folders for different versions.
The third party library folder structure looks like this:
Each and every project defines it dependencies on specific versions of each library. Reverting back to an old version of a project, thus also reverts the dependency to older versions of the library(ies).
Now with third party libraries you generally don't have as many different versions as you can do with your own libraries, but the same principals apply. And to aid in "current development" - where you don't have a particular version number yet, you could simply have a "head" version. Then when you "release" a version of your library, just add that version's folder and adjust the project definitions that have up till know used the "head" because of parallel development, to depend on the new version number...