On Mar 3, 2009, at 6:26 PM, Todd C. Gleason wrote:
>>> 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):
No problem. You aren't expected to know the internals of Subversion.
(Heck, *I'm* still trying to figure some of them out!)
> 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.
All the metadata will be centralized into an sqlite database in the
root of the working copy. The pristine copies of stuff (the text
bases) will be able to live there, or somewhere else, which is
configurable. Straight up copying of a working copy subdirectory will
no longer be supported, but we may implement an 'svn detach'
subcommand which make it still possible.
> 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).
We're talking major performance enhancements, both on disk (think one
big metadata file instead of hundreds of little ones) and speed.
Because the metadata will all live in one place, Subversion will have
a much better idea of the current state of the working copy when
running commands like cleanup/update/merge/commit. status will still
have to walk the working copy looking for unversioned and missing
items, but it becomes just a series of stat() calls, instead of
reading and parsing hundreds of metadata files. In all, we expect
some pretty serious gains (though they are difficult to quantify
without having actually written and profiled the code).
The other big win is that the APIs and other code surrounding the
working copy library will be much simpler and more compact, helping
further development progress more rapidly.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1265095
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-04 06:06:34 CET