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

Re: Feature request: a real backup/restore system for svn.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-06-21 23:24:31 CEST

Matthew Rich wrote:

>On Mon, 2004-06-21 at 13:57, Branko Čibej wrote:
>
>
>>kfogel@collab.net wrote:
>>
>>
>>
>>>Greg Hudson <ghudson@MIT.EDU> writes:
>>>
>>>
>>>
>>>
>>>>Well, that's a good argument for having a backup script based on dump
>>>>files. (I don't think it has to be a huge project, contrary to what
>>>>Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
>>>>shouldn't consider it as a replacement for svnadmin hotcopy.
>>>>
>>>>
>>>>
>>>>
>>>How is it not hot? I thought "hot" just meant that the backup is
>>>performed while the repository is live, and does not affect the
>>>repository's availability for normal use. Dumpfile generation meets
>>>these criteria.
>>>
>>>
>>>
>>>
>>Yes, it does. It's not the most /efficient/ kind of hot backup, but it
>>does meet the criteria.
>>
>>
>
>Hmm, I was under the impression that with svnadmin dump you weren't guaranteed a
>valid backup if there was perchance a write in progess (so you had to pull down
>httpd/svnserve). I always wondered about that, it being transactional and all.
>Was that ever the case, or was it just my imagination?
>
>
Your imagination. :-)
As far as the repository is concerned, "svnadmin dump" behaves as if it
were just another client, checking out revisions one by one. If commits
affected the result of a checkout of an unrelated revision, we'd be in
deep trouble indeed.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 21 23:26:09 2004

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.