C. Michael Pilato wrote:
>Branko Čibej <brane@xbc.nu> writes:
>
>
>
>>> * it's completely specific to BDB. fsfs needs no such thing, and a
>>> future SQL backend will already have its own tools for backup.
>>>
>>>
>>>
>>>
>>So what? Face it: real-life backup strategies, at least those that are
>>efficient, will _always_ be backend-specific. For example, nobody in
>>their right mind would use some Subversion tool to back up their SQL
>>database -- they'll use the database's own backup tools. "svnadmin
>>hotcopy" simply happens to be a BDB-specific backup tool.
>>
>>
>
>Nobody in their right mind would use some Subversion tool to back up
>their Berkeley DB database -- they'll use the database's own back
>tool. Like, say, db_chkpoint, db_recover and db_archive. :-)
>
>
Exactly. That's essentially what "svnadmin hotcopy" does. Used to be we
had hot-backup.py do this instead. So if you want to remove "svnadmin
hotcopy" and resintate that functionality into hot-backup.py, that's
fine -- if you can avoid the race conditions that hotcopy solves, but
hot-backup.py didn't.
But dreaming about a single sloution for everybody is just that --
dreaming. As I said, we should instead list all possible (O.K.,
reasonable) backup strategies and figure out how Subversion can be
integrated into each of them, then talk about solutions. Database dumps,
incremental or otherwise, cover perhaps 20% of the problem space.
Getting too caught up with those 20% without even investigating the
remaining 80% is a waste of time, IMHO.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 18 04:45:26 2004