Shawn Wilton wrote:

> Yeah, still don't understand how you can say that an incremental backup is
> not the same as "backup only the changes".  

I never said these were different. Let's maybe back up a little :) and let
me say that I may have come over too strong in previous messages, that I
never wanted to say that a diff dump in the way you described can not be
used for an incremental backup, and that depending on how svn stores data
in its repository file(s), this may be the adequate or even only way to do
it with svn. (I still may not like it :)

> Again, I will state that backing up revisions is not making a backup of
> the sandbox as you suggested.  It's a *real* backup (if there is such a
> thing) of the contents and the structure of the repo.  Do a dump, ask
> for specific revisions, and you will get the exact repo structure.  Do a
> load, and you get the exact repo structure back including all history. 
> Exact replica.  Again, the assumptions you made, I believe, are wrong.

You are right in that I didn't quite understand what this revision dump
means in svn. I guess I get that now a bit better. But then, if such a dump
really contains the full data of those revisions, it's more than a
traditional diff and is possibly more than an incremental backup would
contain. A traditional incremental backup is just the changed data, and
doesn't allow you to get the full data back without the baseline backup.
Your revision dump, as you say, does that, so it could just be more data
than that incremental backup.

> you prefer to backup the entire repo (why?) 

I probably said I (usually) run an /incremental/ backup over the entire
repository (and not only the repository). Every now and then (usually once
per week) I run a full backup. The reason is mostly that it's cheap, and
guaranteed. I backup to harddrives. It has the added benefit of making sure
all data can be read, and that the disk controller notices early enough
when a sector becomes marginal -- and not only after it's already gone.
Which may make me use my backups less often.

The other reason is that I do this to my whole system, not only the
repository. And here we get to my real beef with that solution: I think
that it's not about backing up this repository or that program's data, I
think it's about making backups of /everything/ as simple and workable as
possible -- so that it gets done, and so that I can go back to work as
quickly as possible in case something bad happens. It has less of a chance
to get done if I have to run a different backup process for every data set.
So I run (baseline and incremental) backups of my whole system. And I think
that's the way to go (if you don't have a sysadmin whose only work is to
admin systems) -- simple and generic. Everything's in there, and I don't
have to work out specific backup and restore procedures for every app or
server that I'm running. 

> But then, I think backing up the entire repo over and over is rather
> wasteful, especially when it has to be done remotely and you have to pay
> for bandwidth (lucky, I don't).

I do that over and over (backing up my system), and I don't see me
producing much waste :)

As the revision diff dump you're talking about contains the full data to be
able to get the complete file set out of them, they are much more than the
difference between these revisions, and sending such diff dumps is
certainly not the most bandwidth conserving way to create an incremental
backup of the repository -- because with every such diff dump you seem to
send the full data necessary to restore all changed files in the change
set. This is probably much more data than a traditional diff patch. So in
this sense, it is not really "incremental", it is more (and more useful,
but also more "wasteful" :) than that.

OTOH, I'm not sure this bandwidth question is relevant in many cases. Few
people pay for bandwidth these days. And as long as we're talking about
source code repositories, few people write that much code. And if they do,
they usually can pay for the bandwidth :)

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist