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, so开发者_StackOverflow中文版me 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/repositoriesYou 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.
精彩评论