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

Re: CVS update: subversion IDEAS

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-22 02:36:22 CET

On Tue, Nov 21, 2000 at 08:03:10PM -0500, Greg Hudson wrote:
> 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.

You could search upwards for the metadata.

Note that your idea is slightly different than what I suggested in IDEAS
(meaning, you might want to add it to IDEAS, also). I meant a single
location for all this data. Say... ~/.svn/

> > + 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.

export SVN_METADATA=svndb:gstein:mysql.lyra.org

Not too hard or clever :-)

> 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.

The backup situation could be wonky, but it could also be part of the local
system's database, or possibly on the LAN. And if you omit the local "pure"
copy of files, then the metadata might not get too large.

But your point about clients having a heavy database is generally true. But
on the other hand, it isn't for us to say one way or another :-)

And, of course, the final point of all this stuff... repeat after me,
"Blue Sky!" :-) ... I doubt that I'd ever get motivated to implement a new
type of storage for working copy metadata. But I have /just/ enough
motivation to talk about, as if I possibly knew something on the matter. :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006

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.