Best Practices for Source Control Dependencies

How do you handle source control setup of a non-compiled project that has dependency on a separate framework or library? For example, Project A uses Framework B. Should Project A also include the code from Framework B in its repository? Is there a way for it to be included automatically from a different repository or would I have to updated it manually? What are the general approaches are usually taken for this scenario? Assume that I control the repositories for both Project A and Framework B and that the source code fo开发者_StackOverflow中文版r both is not compiled.

Any resources or suggestions would be greatly appreciated. I'm currently using Subversion (on a very basic level), but I would like to switch to Mercurial so that I can try out Kiln with Fogbugz.

Edit: In Mercurial, would you use parent repositories for this function?

If you want to use subversion and need to include code from a different repository, Subversion Externals might be an option.

However, if you're dealing with compilable code it might be better to setup a build process that just fetches the required binaries. Build tools like Maven can help you with that.

Most of the time I try to include everything necessary to build the project in subversion. This is using C# and Visual Studio, so most of my dependencies are dlls. Conventions might vary a bit in other environments.

This is usually how I lay out a new project:

• ref
  • SomeOpenSourceProject.dll
  • SomePurchasedComponent.dll
• MyProjectA
  • MyProjectA.csproj (references ..\ref\SomeOpenSourceProject.dll)
• MyProjectB
• MyWeb (references ..\ref\SomePurchasedComponent.dll)
• MyApplication.sln

This way it can be checked out and built by a new developer without much hassle. In the past they used to use a network share for the dlls, but that got annoying as different projects used different versions and if you wanted to go back in subversion or branch or anything, it got hard to keep track of. This structure solved those problems nicely.

I do something very similar to David Hogue, except that it looks like this:

- 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

Most of the inspiration for this setup came from tree surgeon (fairly out of date by now though)

If B is a open source project, and you want to compile it with A, I would suggest you try the vendor drop technique. This way you could keep your own patch.

If B is your company's proprietary code, and you don't want to compile it, it would be much easier just copy the compiled binaries into A' repo.