2009/3/4 Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
> 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.
So will the svn commands, when executed in a subdirectory walk up the tree
looking for the metadata directory? or will all svn commands have to be
executed in the root of the checkout?
>
>
> > 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].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1265735
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-04 14:34:31 CET