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
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.