views:

406

answers:

3

I am new to Mercurial and trying to figure out if it could replace SVN. Everyone I work with has used SVN, CVS and VSS (shiver), so this could be quite a large change. I have been very interested after reading about its merge and branch capability, but have a few reservations.

We are currently on SVN, and have one central repository. From my reading, it seems as though there is no ONE central repository for all projects when using Mercurial. NOTE: We consider each project a separate logical set of code, or a Visual Studio Solution. It runs on its own.

We have around 60 separate projects in our one central SVN repository. After reading about Mercurial it seems to me that I have to create 60 separate central repositories for each one of these projects on the server. QUESTION #1: Should I create a single repository for each project?

If yes, then I am worried about configuring and hosting 60 separate central Mercurial servers. I started thinking I could configure one file, but it seems as if each repository must be individually configured using the “C:...\MyRepository.hg\hgrc” file (Windows install). It also seems as I have to run 60 servers (>hg serve), I would assume on different ports. QUESTION #2: If the answer to question 1 is yes, there should be a single central repository for each project, then how have people managed many multiple repositories?

Finally, I haven’t looked into moving all history and changes from one SVN repository to a bunch of separate Mercurial repositories, but would appreciate any comments from someone who has done this (or if it is even possible).

+2  A: 

You will create 1 central repo per project. If I were you, I would think about hosting via Kiln. It wraps very good review tools and a nice web interface around Mercurial with unlimited repositories and storage. They take care of all the nasty bits of hosting and backing up for you. I would also highly recommend Joel's Mercurial tutorial.

Tom Cabanski
+5  A: 

Mercurial supports "central repositories" just fine, but it does them by convention rather than fiat.

You need run only a single server to run all sixty repositories, and you wouldn't use hg serve for it. Instead you pick one of the production-quality methods from among the publishing options. Likely you'll run hgwebdir behind Apache, Nginx, or IIS depending on your preferences.

Once that's running you can create new repsitories with hg init or hg clone within your repositories directory. At a previous employer we had five products, with a "central" repository for each, and ten to twenty clones of each for various teams and features, all running in a single server. The central repo determines "what's official" but you'll find impromptu repos for unofficial features springing up all the time.

hg serve is for two devs to hand off some changesets in a hurry, but published repos require a little more scaffolding.

Ry4an
A: 

In the simplest manner, you would need 60 central "repositories", all of which can be served using one content/web server. Each repository can be treated as a directory with a path from the root of the server container.

Think of bitbucket or github. They serve thousands of repositories under one server (or most likely one server farm), yet they are each independent of each other, unlike SVN where everything is under one giant repository and shares revision increments.

Santa