views:

52

answers:

1

I'm developing a project in .NET (using C# to be more specific).
Using Visual Studio as an IDE.
Using Mercurial for version control.

I'll be using some third-party libraries:

ThirdParty.Foo.dll
ThirdParty.Bar.dll
ThirdParty.Baz.dll

And some in-house libraries:

Company.A
Company.B
Company.C
Company.D (References third party libraries)
Company.E (References Company.A)

The project itself will have the following components:

Project.Core
Project.DataModel (references in-house/third-party libraries)
Project.GUI (references Core, DataModel, and in-house/third-party libraries)
Project.PluginOne (references Core, DataModel, and in-house/third-party libraries)
Project.PluginTwo (references Core, DataModel, and in-house/third-party libraries)
* can be an arbitrary number of plugins *

I'm quite new to Mercurial, so I don't really know the best way to structure my repositories for a project like this, with a lot of interconnected components.

The in-house libraries are fairly distinct, so I would say that each one of them should have its own repository. However, some of them use functionality provided by others. How should these dependencies be managed?

The project plug-ins should be distinct from eachother, so I'd imagine that each would have its own repository. How should the dependencies on the in-house/third-party libraries and the rest of the project (Project.DataModel and Project.Core) be managed, with regards to the solution layout and the repository layout?

So basically, for a project like this, what are the best way of structuring:
(a) my visual studio solutions
(b) my source control repository/repositories

+1  A: 

You should take a look at Mercurial subrepos. In older mercurial versions this was done by the forest extension. This allows you to nest repositories by placing the other repositories simply in a (deep) subdirectory, but pull/clone/update them all together.

catchmeifyoutry