> > 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.
Given that this is a currently supported use case, it would be a shame
to lose it.
>
> > 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).
That sounds like a terrific improvement overall. Allow me to suggest a
way for third-parties to integrate: If an external program wants to
walk the tree and also install its own hook that gets notified on file
system events, let it also notify the Subversion metadata such that it
won't always be necessary even for status to walk the WC.
What I have in mind is systems such as TortoiseSVN where an optional
TSVNCache.exe sits in the background and does this scanning and handling
of file system events so as to update Windows Explorer icons. (I don't
know whether any other clients do similar things.)
Of course, Subversion could conceivably do this internally too, as an
optional daemon/service. It would probably need a central registry of
WCs to watch, and if the user moved or copied a WC it might have to
re-scan a WC on a subsequent svn command (and update the registry).
> 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.
It sounds like it. I hope the implementation goes well, because I'm
already looking forward to 1.7, and 1.6 isn't even released!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267521
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-04 17:31:51 CET