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

RE: Subversion 1.6.0 Release Candidate 3 Released

From: Todd C. Gleason <tgleason_at_impac.com>
Date: Tue, 3 Mar 2009 16:26:03 -0800

> > Personally, I'd really like to know what are going to be the
> > implications of using SQLite on the client to store metadata, even
if
> > it's not until 1.7.
>
> What particular implications? It will have performance enhancements,
> to be sure. We'll let SQLite do a fair amount of the concurrency
> handling which Subversion core currently has to do, and also let it
> optimize the data layout. The code should get much saner for future
> developers adding new features. Users shouldn't notice anything
> incredibly different, save the speed improvements.

The kind of things I'm wondering are (and forgive me if my questions
betray my ignorance of svn internals):

1. Is the .svn-directory-per-directory going away, or just being
replaced with a SQLite representation of data? If it remains, then
presumably you can still copy a subtree elsewhere and work on it. If it
goes away, then hopefully there will be new commands to achieve the same
results.

2. Will there be merely incremental performance enhancements to
operations that appear to scale according to tree size, or are we going
to see order-of-magnitude or better performance enhancements? And to
which operations will they apply? It would be nice in particular to see
cleanup/update/merge have a better sense of the state of your WC and run
faster. Even better if stat/commit did not have to scan the whole tree
(though it seems to me that this would depend on having something
running in the background).

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1264132

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-04 01:27:54 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.