How SVN works wrt copies of versions - Was: Please think about incrementel sync Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone

Josef Wolf jw at
Tue Dec 5 23:17:37 CET 2006

On Sun, Dec 03, 2006 at 04:20:10AM +0100, EdorFaus wrote:
> On 11/30/06, Tin Newsom <cephdon at> wrote:

> > If you are keeping a copy of the current versions locally then diffing and
> > sending only the diffs would be easy... but to my knowledge svn only keeps
> > the diffs between versions at the repository. Someone who knowns please
> As far as I know, this is essentially correct - the repository contains the 
> original file, and the diff for each version since then. This is, afterall, 
> enough to recreate any version.

Actually, it's a little bit more tricky.  They don't keep consecutive
diffs but diffs to get to the next lower 2^N revision.  With this method
they can retrieve a specific revision with O(log N) instead of O(N).
This costs more disk space than storing consecutive diffs.  But since
the repository is on the server, that should not harm in this application.
After all, disks are cheap nowadays.

Google for "delta combiner" or "skip deltas" if you are interested in
details on this.

But the delta's are only internal storage format.  For transport, always
diffs against the "base revision" (see below) are used.  Using apache
for repository serving, those diffs can even be compressed.

> I believe this is exactly what svn does. It certainly keeps a copy of the 
> last-committed (or updated-to) version in every working copy, along with the 
> version being worked on. This allows it to do various things while offline.

Exactly.  It keeps the "base revision" (they call it "text base").  This
is the revision your local files are based on.  You can see which revision
this is with "svn st -v"

When I was lurking at svn mailing lists years ago (it was around svn-0.17
or something), once a month came the request either to remove the text
base completely or to compress it.  I bet the requests are still beeing
made once a month.

> No, but I believe this is how CVS works - SVN on the other hand only
> transmits the diffs in either direction, [ ... ]


> > If you don't keep a repository locally then one way or another you will
> > have to obtain a copy of the old version in order to just sync changes
> > somehow..
> This being, I believe, one of the main reasons SVN does keep a copy (of the 
> latest-known-committed version) locally.

svn-1.4 includes a svnsync utility.  This is meant to replicate/sync
repositories.  Form the description on subversion's homepage I deduce
that svnsync is just a reimplementation of svk.  But I haven't done a
look at it yet, so I can be wrong.

> Some other good reasons are things SVN can then do offline, e.g.
> 	- generating diffs (what exactly did I change this time?)
> 	- reverting a file (nono, that's no good, let me start over...)
> It can then also more easily update the working copy with new code from the 
> repository, by seeing local diffs vs diffs in the repository.
> It only keeps one previous version in the working copy though, so for 
> comparing with or reverting to earlier versions, it must still be online.

AFAICS, with svn-1.4, this is no longer true.  You can keep a local
copy of the repos at the cost of disk space.  You do your ordinary
work against this local copy.  When you are at home, you sync the
local repos against the main repos with svnsync.  Too bad you can't
attach 1.8 inch USB disks to Neo due to USB beeing non-powered :-(

> > Its an interesting thought.. does anyone know for sure if SVN sends back
> > only the changes and how it does that if it doesn't fetch the previous
> > version for comparison?

SVN have even more selling points:

 - Can be served by apache with SSL, so you get encryption+authentication
 - Can use apache's mod_deflate to compress the diffs before sending them
 - You can setup apache so that you can browse/download newest revision
   with ordinary web-browser.

More information about the community mailing list