Greg Stein committed:
> + Benefit of a single database: apps/systems that nuke a directory and
> + rewrite it will no longer "unhook" the working copy from SVN (since
> + the data is stored elsewhere).
So, my idea on this front is that we support a directory property
which asserts "this directory is manage by an app; don't keep metadata
here." Metadata for such a directory would be kept in the SVN subdir
of the youngest ancestor directory which doesn't have that flag set.
You wouldn't be able to run svn commands while inside such a
directory, but you generally wouldn't want to, since the directory is
managed by an app.
> + Benefit of a "true" database: there is a lot of effort expended in
> + the current libsvn_wc to transact the changes, record logs of
> + changes, and to perform them in an atomic manner. A transacted
> + database on the client side could potentially simplify much of that
> + work (and the corresponding I/O to track it).
Obviously you don't get these benefits from my idea. But you retain
the ability to run svn commands in working directory subdirs without
forcing the client to be extra-clever about finding the metadata.
Also, creating a huge database file for the working directory which
gets touched by almost every svn command could create a backup
nightmare, or perhaps a performance nightmare for some distributed
filesystems.
(I'm less concerned about having one huge database on the server.
There are fewer servers than clients, a repository is less likely to
have only small, isolated changes made between backups, servers often
use big database files already, servers can use specialized backup
programs if it's really necessary, etc..)
Received on Sat Oct 21 14:36:15 2006