Can Git or Mercurial be set to bypass the local repository and go straight to the central one?

Using Git or Mercurial, if the working directory is 1GB, then the local repository will be another 1GB (at least), residing normally in the same hard drive. And then when pushed to a central repository, there will be another 1GB.

Can Git or Mercurial be set to use only a working directory and then a central repository, without having 3 copies of this 1GB data?

(actually, when the central repository also update, then there are 4 copies of the same data... can it be reduced? In the SVN scenario, when there are 5 users, then there will be 6GB of data total. With Distri开发者_StackOverflow中文版buted Version Control, then there will be 12GB of data?)

Update: it is strange -- I just tried to look at a project I cloned using Mercurial: the working directory not including the .hg folder is 126MB, but the .hg folder is 239MB. And it is a new clone... is it because my new repository actually contain all the history / revisions, so that's why it is double the size of the working directory?

Git or Mercurial are distributed version control systems. This means that every checkout contains the whole history of the project. Bypassing this would defeat the whole purpose of using a DVCS (every operation can be done offline).

But in general Mercurial or Git have a very high compression ratio, often better than svn even if they store the whole history.

hg clone create hard links on unix file systems, so only changes introduced by new change sets use space in the storage. When you don't want a working copy, you can update the repo to the 'null' revision, which consist only of the repository without working copy.

Git also has the option of bare repositories and shared repositories, but I never tried them.

You can do what you're asking as long as you have the filesystem with the "central" repository mounted and accessible locally.

From cmd.exe:

git --git-dir=Z:/path/to/git_repo_dir --work-tree=C:/path/to/checkout/root checkout master

And you can do this for as many checkouts as you want, but it's not really ideal. It's true that git doesn't work quite as well on Windows as it does on Linux - the ideal solution is for each clone to have hard links to the objects, so they're only physically stored on disk once, and then each clone can be checked out to a different branch, so you could track development/testing/production all at once, for example.

Also, as far as your concerns about disk usage go - try doing git gc --aggressive --prune on one of your repositories and see if it's still taking up a huge amount of space. In my experience, git is very good about storing only binary deltas - I have tested this by adding a directory full of MP3 files to a repository and committing them, changing the ID3 tags, and then committing the changes, and before I ran git gc there were clearly two copies of each MP3 in the .git folder, but after the git gc the size went back down to just slightly larger than the original working directory.