How does the SVN repository work?

Franz · 2009-02-04 19:19:24

Is there anybody out there who knows or who could point me to a site that knows how the SVN repository is built up?

I can't imagine it saves every revision of every file, that would take up too much memory. On the other hand, when saving everything in diffs, it would take a lot of time to see e.g. the difference from revision 20 to revision 846 because all diffs would have to be "added" together.

Thanks in advance.

Connor · 2009-02-04 19:27:21

http://svnbook.red-bean.com/nightly/en/index.html Probably in there somewhere

jmp · 2009-02-04 20:40:26

lie2815 wrote:

Is there anybody out there who knows or who could point me to a site that knows how the SVN repository is built up?
On the other hand, when saving everything in diffs, it would take a lot of time to see e.g. the difference from revision 20 to revision 846 because all diffs would have to be "added" together.

I think most VCS use deltas. It’s fast because the deltas are often a linear chain in the changeset history (i.e. each delta is based on the previous revision of the file). I don’t know about SVN, but in a benchmark a while back Mercurial committed 20 MB worth of patches (in multiple files) in slightly over a minute, which sounds pretty fast to me. I’m guessing the times for viewing diffs of single files are faster than commits, since you would have to go only the changeset history of that particular file.

Last edited by jmp (2009-02-04 21:48:42)

Frank H · 2009-02-04 21:44:29

Connor wrote:

http://svnbook.red-bean.com/nightly/en/index.html Probably in there somewhere

Yep

To keep the repository small, Subversion uses deltification (or deltified storage) within the repository itself. Deltification involves encoding the representation of a chunk of data as a collection of differences against some other chunk of data. If the two pieces of data are very similar, this deltification results in storage savings for the deltified chunk—rather than taking up space equal to the size of the original data, it takes up only enough space to say, “I look just like this other piece of data over here, except for the following couple of changes.” The result is that most of the repository data that tends to be bulky—namely, the contents of versioned files—is stored at a much smaller size than the original full-text representation of that data. And for repositories created with Subversion 1.4 or later, the space savings are even better—now those full-text representations of file contents are themselves compressed.

http://svnbook.red-bean.com/nightly/en/ … ace.deltas

Franz · 2009-02-05 07:36:37

Thanks, guys.

Franz · 2009-02-05 08:40:51

So, the repository makes a diff out of every changeset for the changed files?

My problem is that it must take a lot of time in a big repository with, let's say, 10000 commits, to view the differences of a file from revision 1 to 10000...

Do I get this right?

jmp · 2009-02-05 09:33:41

lie2815 wrote:

So, the repository makes a diff out of every changeset for the changed files?

Basically yes, but usually the diffs are also compressed to save space.

lie2815 wrote:

My problem is that it must take a lot of time in a big repository with, let's say, 10000 commits, to view the differences of a file from revision 1 to 10000...

Again, I don’t know how Subversion handles this, but Mercurial creates compressed snapshots of the files (i.e. saves the full file) between a certain amount revisions, and uses an index file to determine where the snapshots and changesets are stored in the Mercurial filesystem. So if you want to view revisions between 1 and 10000, you might only need to take rev1, all diffs between the latest snapshot (say rev9950) and rev10000 merged, and show a diff between those. So at the end, the VCS could end up going through only a few diffs.

Franz · 2009-02-05 09:36:07

Jarkko wrote:

Again, I don’t know how Subversion handles this, but Mercurial creates compressed snapshots of the files (i.e. saves the full file) between a certain amount revisions, and uses an index file to determine where the snapshots and changesets are stored in the Mercurial filesystem. So if you want to view revisions between 1 and 10000, you might only need to take rev1, all diffs between the latest snapshot (say rev9950) and rev10000 merged, and show a diff between those. So at the end, the VCS could end up going through only a few diffs.

Ah, that sounds better. Can anybody confirm this for SVN?

ridgerunner · 2009-02-09 01:17:06

If you'll pardon me veering off-topic briefly...

Last summer I was looking into the whole version control thing and ran across a very interesting talk by Linus Torvalds where he discusses GIT, the version control system used by Linux. The running time is 1 hour 10 minutes and he describes why he hates SVN (and CVS, and all other centralized systems). Although a distributed system like GIT likely does not apply to a small project like FluxBB, (SVN works just fine), I thought some might be interested in hearing about it. I sure did.</offtopic>

Tech Talk: Linus Torvalds on git

Forums

Announcement

#1 2009-02-04 19:19:24

How does the SVN repository work?

#2 2009-02-04 19:27:21

Re: How does the SVN repository work?

#3 2009-02-04 20:40:26

Re: How does the SVN repository work?

#4 2009-02-04 21:44:29

Re: How does the SVN repository work?

#5 2009-02-05 07:36:37

Re: How does the SVN repository work?

#6 2009-02-05 08:40:51

Re: How does the SVN repository work?

#7 2009-02-05 09:33:41

Re: How does the SVN repository work?

#8 2009-02-05 09:36:07

Re: How does the SVN repository work?

#9 2009-02-09 01:17:06

Re: How does the SVN repository work?

Board footer