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