[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Newbie question

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: Fri, 11 Jan 2008 15:01:40 -0600

On Jan 11, 2008, at 08:25, Craig Rubendall wrote:

> I have a large directory of various files (and file types) and
> nested subdirectories. These files are updated by numerous
> different processes. What I would like to be able to do is to
> use the "real" directory as a "working set" and to use subversion
> to create a "versioned, delta backup" repository of the files in
> this directory. Is this a realistic use of subversion? I know
> there are probably other true backup tools out there, but this is
> the first thing that came to my mind.

I'm not sure I understand the question... you may need to rephrase it.

Subversion stores changes in the repository as deltas against a
previous version (not necessarily the immediately previous revision;
see the skip-deltas algorithm) so it's efficient in that regard.

But once you store something in a repository, it's there "forever"[1]
and can't be removed. This isn't generally a good property for a
backup system to have, and Subversion is not intended to be a backup
system. On the contrary: you should have a strategy by which you back
up your Subversion repository.

You may also want to consider that a working copy stores two copies
of each file -- the one you are (or might be) working on, and a
hidden pristine copy so Subversion can efficiently figure out what
you changed when you commit. This isn't so great if you're storing
large files (I don't know if you are).

[1] Things can be removed if you use svnadmin dump / svndumpfilter /
svnadmin load but that's a tedious process and fraught with

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-11 22:02:47 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.