Harvey, Edward wrote:
>>> When you want to edit a file, you run 'svn edit file', which makes
>> the
>>> file read-write and registers this fact in sqlite. Then, when you
>> run
>>
>> If I would be required to call svn [edit] I would stop using Subversion
>
> You won't be forced to use it, it's optional, for the purpose of gaining performance. By comparison, getting status on a directory that takes 5-10 mins in svn will be nearly instant (less than 1 sec) on perforce. That's the performance gain that svn will be able to achieve by using "svn edit"
[Note: I personally don't find the idea of 'svn edit' very palatable, but can
understand why others would.]
I think we have a long way to go toward improving the current method of doing
things (i.e., wc-ng), and suggest that we pursue those avenues before going off
into uncharted territory. We should be doing comparisons against the
new-and-improved code (when ready) to see how much the current behavior can be
attributed to an old working copy library.
>
>> Isn't this a problem of the filesystem if comparing file modification
>> times is
>> so slow? Is there really no filesystem (Reiser, ext3/4, XFS, ...) which
>
> If you have tens of thousands of versioned files in your working copy, regardless of how fast your filesystem is, it takes a significant time to walk the tree scanning for stuff that changed. Which must be done on every "svn status" and "svn update" etc.
I can understand why 'svn status' crawls the filesystem, but 'svn update'? It's
just replaying an editor drive from the repository and applying those changes
locally. I would think that the costs in update aren't filesystem crawls, but
rather the I/O associated with doing the update, updating the pristine copies,
and working with the entries file. Some of this is just the cost of doing an
update, and some of it will be improved through the use of the new working copy
library. (Disclaimer: it's been a while since I've been in the 'svn up' code.)
Again, let's see how current improvements work out before rushing off to add new
features which cover up, not fix, the underlying problems.
-Hyrum
Received on 2008-10-27 15:40:12 CET