How many repositories should I use to maintain my scripts under version control?

I mainly code small programs for myself, but recently, I've been starting to code for my peers on my team. To that end, I've started using a Mercurial repository to maintain my code in some form of version control (specifically, Tortoise-Hg on Windows). I have many small scripts, each in their own directory, all under one repository. However, while reading Joel's Hg Tutorial, I tried cloning a directory for one of my bigger scripts to c开发者_开发百科reate a "stable" version and found I couldn't do it because the directory wasn't itself a repository.

So, I assume (and please correct me if I'm mistaken) that in order to use cloning properly, I'd have to create a repository for each script/directory. But.. would that be a "good idea" or a future maintenance nightmare waiting to happen?

Succinctly, do I keep all my (unrelated) scripts in one repository, or should I create a repository for each? Or some unknown third option?

Use separate repos for everything that you might want to use independently at some point. It's very easy to combine repos in the future and much harder to pull them apart. The subrepos feature (like svn externals) even lets you make an umbrella repo that includes all the small repos if that's still something you'd like to be able to clone in a single command.

In principle, separate repositories sound great. But I'm not sure this approach scales. I have written over one thousand scripts in my ~/bin directory alone. These are all stored in a single repository. These scripts are small: the average length is 150 lines, but this is misleading—only about 15% of the scripts are over 100 lines.

I can't see the use case for putting them in separate repos. If I want to share with fellow developers, I generally just send source code. They don't change a lot: half the scripts haven't been modified since June 2005, and only 5% have been modified in the last six months. So most of the code is reasonably stable, there aren't a lot of bug fixes, and the history isn't interesting.

I would go with a single repo until you see a demonstrated need.

Use a repository for each project and for each logical block of mini-projects.

hg subrepo functionality is not ready for prime-time yet, in my opinion; quite a few of the core hg commands don't understand subrepos and therefore you can stab yourself quite handily, especially with shared code. You can find more info about subrepos in the latest patch notes for hg.

Creating a separate repository for each actual directory would probably be a good idea, as it separates it from the rest of your code. Just as modularity in coding is beneficial, so is modularity in repositories. If you wanted to publish one of your scripts on something like GitHub, it is easier if the repos are already separate.

However, if you have a bunch of small scripts that are one file long, you probably are fine keeping them under a single repository. However, if you ever wanted to release the revisions of it, you would have to release all of them at once.