tags:

views:

339

answers:

4

My company is switching from Subversion to Mercurial. We're using .NET for our product. We have a solution with about a dozen projects that are separate modules with no dependencies on each other. We're using a central repo on a server with push/pull for our integration build.

I'm trying to figure out if I should create one central repo with all the projects in it, or if I should create a separate repo for each project. One argument for separate repos is that branching the individual modules would be easier, but an argument for a single repo is easier management and workflow.

I'm very new to hg and DVCS, so some guidance is greatly appreciated.

ETA: At hginit.com, Joel says:

[I]f you’re used to having one big gigantic repository for the whole company, where some people only check out and work on subdirectories that they care about, this isn’t a very good way to work with Mercurial—you’re better off having lots of smaller repositories for each project.

It'd be great if someone could expand on this or point me to more documentation.

+4  A: 

One thing you should take into consideration here is the fact that Mercurial does not support checking out directories like subversion does. One typical subversion setup is to have one giant repo with multiple separate projects in it, and when somebody needs code they will just checkout a subdirectory containing that project. You can't do this in mercurial. You either take the whole repo, or nothing. If everybody working on these projects does not need all the code, all the time, you might want to split it up into separate repositories.

EDIT: This link might be helpful in setting things up, in particular the "Publishing Multiple Repositories" section.

TwentyMiles
The devs on my team are all SVN users, so they're thinking along the lines of "checkout." They think, "If I'm working on the scheduler code and a developer commits charts code, I need that charts code. How do I get it?" With one repo, that's easy. But with multiple repos, and on maintainers, what's the workflow?
Robert S.
This may be an issue of discovery, i.e. how does a developer know which repository to clone, and where it is? I've added a link to my post with some info on setting up and publishing multiple repositories.
TwentyMiles
For us (java with maven) mercurial repos worked best, when split into the smallest possible logical unit. So in practice if we had an API for a project, then that was placed into it's own repo. Impl code went in its own repo. This workflow requires clever use of subrepos, and/or a habit of pulling to the repositories often. The workflow was beneficial in the terms of CI, since the setup is then easy, and the feedback loop is fast. We did our change discovery e.g. by RSS-feeds from the CI. One could always easily see if/when something had changed, because it then went through the CI cycle.
Kai Inkinen
A: 

I'm fairly new to Mercurial myself (my company is making the leap from SourceSafe) so I don't know what more experience would say.

For me it makes sense to have one repository per Visual Studio Solution. If your modules are truly not dependent on each other, why are they all in the same solution? If you have a good reason for them all being in one solution, then that's probably the reason to keep them in one repository. If there's not a good reason for them to be in one solution, then a repository and a solution for each makes more sense to me.

Edit: So, since all the modules are built together and need to integrate, that would push me towards a single solution and a single repository.

Mercurial does a great job of merging, but the one thing I've had issues with is the solution file when merging the addition of more than one project at a time. It gets confused with multiple End Project lines. So, as long as you aren't adding new projects very often, your merges should be smooth.

Dennis Palmer
They're in the same solution because that solution is sort of the "integration build." Since the app is a WPF app, testing the UI elements requires running the entire project with all the modules integrated together.
Robert S.
+1  A: 

if completely separate repos don't work for you maybe have each project as a subrepo of some umbrella repo. I have to say that seperate repos sounds like what you need though given that each project sounds totally independent.

jk
A: 

From my experience, and not based upon studies etc, I would say that each logical blob is a repository. If you share code between subprojects, they need to be in the same repo. There will be full subrepo functionality, but currently (apr 2010) it's not fully implemented.

Paul Nathan
If there are some common components, then those could be stored in separate repos, to be included in each depending project. This way, one doesn't need to copy-paste modules, but still get the library code close to the project. I don't think that recursive subrepos are supported, so tricky dependencies are not necessarily handled this way.
Kai Inkinen