Question: Let's say I create a repository, add **x** files to it and commit. Say the size is **a** Mb after the initial commit. 

* Is there any way to estimate how large the repository is going to be in one years time?
* If the lines of code has increased by 10%, will the repository have grown accordingly?
* How does number of commits, branches, tags etc. factor into the repository size?
* Will 10000 commits the same year make the repository grow (noticeably) more than say 1000 commits?
* Maybe my question is wrongly phrased?

Answer: 
Changes to a Mercurial repository are stored as either a complete file or as a compressed delta against the previous version:

<https://www.mercurial-scm.org/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.How_does_Mercurial_store_its_data.3F>

Mercurial makes the decision about whether to store a complete file versus a delta based on the amount of changes made.

This means that it's not just adding lines of code that will increase the total size of a repository, but also:

1. The number of changes made to existing code.
2. The number of changes made to each file per commit.
3. The number of files that are added and subsequently deleted.

Mercurial retains all deleted files. You could add a 1GB file to your repository and then delete it; the number of lines hasn't increased, but because the file remains in the repository, the repository will be considerably larger.

To answer your questions in turn:

* I imagine it's feasible to roughly estimate the size of a repository after x months, assuming that you maintain a steady rate of change to the repository in total (ie. you add/remove/alter files at the same rate, changing roughly the same number of lines per commit).
* Increasing the number of lines of code by 10% doesn't tell us how many lines were deleted/altered, so an increase in lines of code won't necessarily correspond to the same increase in repo size.
* Tags don't affect Mercurial repo size by more than a handful of bytes. Nor do branches, until you start working on them, at which point they add the same overhead as working on the tip. Number of commits should be reasonably proportional to the repo size, assuming the same rate of change occurs.
* Committing 10x as often probably won't increase the file size, as it is the rate of change that is the main influence on repo size, not number of commits.
Take a look at [GitBenchmarks](https://git.wiki.kernel.org/index.php/GitBenchmarks) page on Git wiki, the section "Repository size benchmarks" and "Other benchmarks and references" (taking into account *when* the benchmark was made, and what *versions* it uses), in particular the entry at the end page:

* [DVCS Round-up: One System to Rule Them All? -- Part 3](http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3) by Robert Fendt on Linux Developer Network, from 27-01-2009, contains results of two synthetic benchmarks testing how a system acts under stress (number of commits in repository, or number of files comitted).

The test system was a VM running Ubuntu 8.10, and the software versions used were SVK 2.0.2 (last is 2.2.3), darcs 2.1.0 (last is 2.4.4), monotone 0.42 (last is 0.48), Bazaar 1.10 (last is **2.2.1**), Mercurial 1.1.2 (last is 1.6.4), and Git 1.6.1 (last is 1.7.3).