On Oct 26, 2008, at 9:03 AM- Oct 26, 2008, 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"
>
>
>> 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.
>
> For my users, it takes 5-10 minutes every time they "svn status"
> their WC. As long as the cache is cold (and it usually is because
> the system is busy working on peoples' files too besides just
> versioning them). On a warm cache it's 20-30 sec, but there's no
> reasonable way to keep the cache warm.
This is the kind of performance issue that I was hinting at in the
thread from a couple of days ago "Re: Subversion Performance (was Re:
fs-rep-sharing branch)"
As I said before, performance is the biggest issue facing Subversion
today. Lets think very hard before we introduce any improvements that
make things any worse than they already are. For centralized SCM
Perforce is our only real competition, but there's absolutely no
reason why we can't get at least as good as them. The "svn edit"
optional command will get us 90% of the way actually.
BTW: for the poster that thought p4 is some obscure, irrelevant tool
you're very wrong. Just ask the 3k(+) at Google and the 500k users
worldwide.
Thx again.
Received on 2008-10-26 19:50:25 CET