I've worked with more pleasant systems, but they are not public and I don't feel comfortable talking about them publicly in much detail.

Basically though, repo is good for a single project ("Android", as a collective entity) but a company looking at working with many repos will want something designed with handling many unrelated projects at once. (For example, all the repos for "Android" and all the repos or "ChromeOS" should be able to live alongside each other in this system without any developer hassle, even though they may not have anything to do with each other).

Also repo is really only one part of the solution a company should look at. Properly done, the sort of system that I am talking about is really several systems that are all basically on the same page. Your build servers should understand how to get the code they need to build something, your internal code search/browsing tools should understand where code lives, etc. Re

Furthermore, allowing different types of repos to exist alongside each other is a good idea. That way each team can individually decide if they want to use Mercurial, Git, or even SVN.. To my knowledge, the repo script is only good for many git repositories.

Would you be willing to chat about it via email? I'd love to know more, as I'm starting to look at implementing something like this and it'd be nice to reuse any work that someone has done in thinking through mistakes before I make them...

(my email is listed in my HN profile)

My product is a read-only solution, which simplifies my technical requirements, but it basically de-emphasizes the repository, by making branches the focal point. If you have ever worked with UCM ClearCase by IBM, you'll understand that everything works at the stream/branch level. When you create a new UCM project, you construct it by picking points (baselines) from streams/branches, which can come from different pvobs (repositories). And UCM activities, which are like commits, can contain changes from different branches from different pvobs (repositories).

I personally think, if you want to take Git to the next level, you'll have to implement something like UCM ClearCase activities and projects. Commits should not be bound to a single repository and it should be very easy for people to say I want to create a product that uses starting points from branches x, y and z without having to think about what repo they belong to.

I have a couple examples that shows how my product de-emphasizes the repository. In the following example, you can see my Commits Finder tool, which lets you search for commits by branches.

http://ny.testdrive.gitsense.com/index?#pid=13&cid=20&trail=

As you can see, the search results shows commits from 10 different branches from 7 different repositories. My other example is my GitHub Pulls Finder tool which lets you search for pull requests by branches.

http://ny.testdrive.gitsense.com/index?#pid=24&cid=29&trail=

Here you can see pull requests from 6 different branches from 6 different repos.

Since my solution is read-only, it simplified things, but I don't think creating a nice layer on top of sub-modules would be be that technically challenging. And it's the direction I would personally go if I wanted to make Git more enterprise friendly.

I participated in creating and open sourcing Guestrepo for hg. It is a very nice multirepo infrastructure, in my humble opinion. ;-)

https://bitbucket.org/selinc/guestrepo

+1. I was reading the Mercurial mailing list while the Guestrepo design was being hashed out, and i was really impressed: the goals and mechanism were carefully considered. I haven't actually used it, so i can't vouch for the implementation!