On Mar 4, 2009, at 10:30 AM, Gleason, Todd wrote:
>>> 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.
Agreed, but empirical evidence suggests that the current detachable
working copy paradigm is not exploited very often.
>
>>
>>> 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).
There are various thoughts and proposals floating around regarding
this. I'd personally like to see Subversion tie into the FSEvents API
on OS X and get filesystem change information directly from the
operating system. Unfortunately, Windows doesn't provide such a
service yet. :/
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267538
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-04 17:36:53 CET