How should I version control (sort of) unrelated scripts in the same path?

Grouping of files based on their functionality should be based on

1) Name.

2) Folder they are in.

Just give a proper name for the scripts. If there are multiple related scripts group them into a folder. Having one script per folder makes no sense. You end up with almost same number of folders as scripts.

All this in a single repository. Generally, people have multiple projects in a single repo. Creating multiple repos, especially for a few files means lots of overhead. If the script is not "stable" use branches. That is what they are for and merge them back.

And don't worry how many "changesets" are there in the repo!

PS: Might seem a bit opinionated, but there is no real right or wrong answer for what you ask.

Step back, relax, and ask yourself if this is premature optimization. A primary benefit of using VCS is that you do not need to worry about starting with the "perfect" solution. DVCS tracks change history across renames & moves (use hg mv, or try auto-detection with hg addremove --similarity).

These scripts are in a ".\Scripts" directory that is added to $env:PATH so I can easily run them from the command line. Since these scripts aren't really related to each other, it doesn't make much sense to create a single repository for the Scripts directory

If the scripts are all in the same directory, it certainly makes sense to track them in the same repository.

• Use temporary repositories until the script is "stable" ...

A "temporary" repo defeats the purpose of having a repo, which is to have a history of changes.

This would reduce the number of changesets introduced to the "Scripts" repository.

As @manojlds said, there is no reason to worry about the number of changesets. None.

My advice:

• Put your experimental scripts in a directory like ./Scripts/incubating/
• When a script matures, put it in ./Scripts/ or ./Scripts/Foo/ or whatever; use hg mv to help Mercurial track the move/rename
• • Or use hg addremove --similarity to auto-detect moves/renames
• The script's change history is preserved and you can reorganize your script directories as your collection evolves

I think the chaps here have some good ideas and have pointed out you may be focusing a little too much on it. For completely carefree source control see Tome's guide http://powertoe.wordpress.com/2010/12/12/why-every-it-pro-should-use-mercurial-for-source-control-with-their-powershell-scripts/

I've followed this method and found it very useful. 2 reasons I've found source control useful:

1. having a bad day and rewritten a script so that it doesn't do anything you want it to and you can't remember how to get it back!

2. changes in needs, sometimes you need a script to monitor or do something for a short period and then need it to revert to the original set up. easily done with source control.

As such, having all the scripts in one repo isn't really an issue.

I did wonder if you can use it to synchronise computers as well (automatically instead of pushing\pulling when needed) but it's not something I've had time to look at.