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

Re: backing up a repository over a network

From: <cmpilato_at_collab.net>
Date: 2003-06-10 00:57:02 CEST

Faheem Mitha <faheem@email.unc.edu> writes:

> On 9 Jun 2003 cmpilato@collab.net wrote:
> > Understand that it's not logging the checkout or update, per se. The
> > repository database contains trees of files and dirs ("revision
> > trees"). When you do an update, we make another temporary tree, which
> > we store in the database, that has the same files as dirs as your
> > working copy ("transaction tree"). We then diff your transaction tree
> > against the revision tree you're updating to, and that's how the
> > repository knows what you need as part of your update. Finally, we
> > delete the temporary tree.
> >
> > It's only the creation and removal of that temporary tree that is
> > loggy in the database, and generally, we're not talking about a whole
> > lot of write operations. It's proportional to the amount of revision
> > variation in your working copy (like, how many paths are at different
> > revisions than their parents), not to the size of the update.
> Hang on a second though. In my example (in my first message) I had
> completed the checkout on the remote repository before I ran the rsync
> backup script again. So if there were temporary files/dirs created, why
> were they not deleted and the repository returned to its previous state?
> Or is this simply not guaranteed for some reason?

Without seeing exactly what you did and in what order you did those
things, I'm not able to really poke a guess at what ails you. All I
can say is that the folks at Sleepycat recommend a particular
algorithm for making hot backups of Berkeley DB environments which is
guaranteed to not screw stuff up, and it is that algorithm which
hot-backup.py follows.

If we can agree on two things,

   (1) that the hot-backup.py algorithm is the only one which
       guarantees a usable backup repository, and
   (2) that rsync will faithfully copy byte-for-byte filesystem
       segments across a network,

then I think we have a recipe for scratching your itch. To use
another non-Sleepycat-sanctioned backup method on a live repository
takes us into the realm of academic discussion -- not my favorite
flavor. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 10 00:57:55 2003

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

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