Where does Subversion physically store its DataBase?

Question

After reading many introductions, starting guides, and documentation on SVN, I still cannot figure out where is my versioning data stored. I mean physically. I have over EDIT [1/2 GB] of code checked in, and the repo is just a few MB large. This is still Voodoo for me. And, as a coder, I don't really believe in Magic.

EDIT : A contributor stated that not all the code was stored in the repo, is that true ? I mean, if I delete my local working copy I still can get back my source code for the repository... If so, I still can't understand how such a compression can occur on my code...

EDIT 2 : When I import the code into repository I have the message "50MB uploaded" and the actual repo is much smaller. Compression Algos must be involved.

BTW, It's funny to read some answers and see how many people DO Indeed believe in Magic, and use SVN without REALLY Knowing what goes on behind the scenes...

Answer 1

It depends on what you're using for your Subversion server. I use VisualSVN Server, and it saves the repository files in c:\Repositories.

Answer 2

Putting this as an answer, per Mika's request:

I'm surprised by how many people have this answer wrong. The .svn folder is NOT where the server stores its files (because that is local to the machine - nobody else would be able to check out that information), and, while SVN only stores the diffs (assuming FSFS), it has to store the originals SOMEWHERE.

Of course, as @csharptest.net said: "My guess, 70% is perf data, the other 29.99% is in 'obj' and 'bin' directories. leaving you with the 10mb of actual code checked in." So you're not actually checking in all that information anyway. Most of it never enters the repository. In addition, SVN uses a lot of compression algorithms and various techniques and does not necessarily store your data byte for byte within the repository. That may be why you are seeing a difference in size.

If you're interested in reading more of how SVN works, read about it at this Stackoverflow answer.

Hope that helps!

Answer 3

Your svn repository is stored in a folder in the filesystem, it should contain sub-folders like: conf, dav, db, hooks, locks. These folders make up the repository.

There's an svnadmin tool you can use to manage the repository.

Answer 4

It's stored in the filesystem. Exactly where depends on how the system was set up. Also, when you create a new repository, it can be anywhere on your filesystem. Your install will have a default location, but creating a new repo can be done anywhere, do you may have to look around to find the actual path.

This is done in the command line version like so:

svnadmin create d:/path_to_repository 

In the above example, the repository is stored in "d:/path_to_repository "

Also, when looking at the mount of code you have in your local machine, are you filtering out content that does not go into the server? You should have a global ignore list to exclude items that have no business in source control. (user-changed content, usually compiled projects, etc.) You may be overestimating the actual size of your repository.

Answer 5

Why don't you check out a new working copy, build there, and verify that everything still works? We can all write answers here and guess how many % might be where, but in the end, you should still check that everything that needs to be added to Subversion is.

Answer 6

I realize this is an older thread, but after reading it, I thought I'd throw in my $.02.

Contributing factors to a large local file set in a working copy are:

• As mentioned, the working copy meta/state-data lives in the hidden (by default) .svn directories. While the meta data is pretty small, for each file in the working copy, there is a working copy baseline. This will simply double the disk space consumed for any file that lives in the repository.

• If your repository includes any copied paths (typical in the case of branches or tags) you could end up with many times the physical space used. This is because the real space used in an SVN repository for a "logical" copy is tiny. It's really just a pointer back to a particular revision of the source path. You could duplicate your entire repository with a copy operation that results in new repository data of only a few hundred bytes (this is also why any copy operation takes the same, short amount of time). Yet, when you check out or update the working copy it could be twice as big as before you copied it. This is typically why one would use a switch operation to change a working copy over to a branch or tag of a logically copied path instead of recursively checking out an entire repository from its root.

I too have been very impressed by how compactly SVN stores and transfer its repository data.

Answer 7

Hidden .svn folder in each versioned folder.