[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: performance enhancement by working copy svn server

From: Branko ─îibej <brane_at_xbc.nu>
Date: Fri, 11 Apr 2008 09:38:52 +0200

Ben Collins-Sussman wrote:
> On Thu, Apr 10, 2008 at 3:43 PM, John Peacock
> <john.peacock_at_havurah-software.org> wrote:
>
>> Benjamin Smith-Mannschott wrote:
>>
>>
>>> Yuck. At first blush, this seems to me a pretty unnatural way to work.
>>>
>>>
>> Me too.
>>
>
> I think hundreds of thousands of perforce users would disagree with
> you guys. ;-)
>

Feh. Hundreds of thousands of CVS users thought CVS was great until they
tried SVN.

> I have to admit, when I first started using perforce a couple of years
> ago, it seemed strangely restrictive compared to cvs or svn. But now
> running 'p4 edit' doesn't seem any weirder to me than running 'svn
> add', 'svn rm', 'svn mv', or 'svn cp'. It's just one more case of
> telling the system what you're doing. And holy awesome, what an
> incredible speed boost you get in return!
>

I agree wholeheartedly with what John wrote in his reply. Scanning a
disk can be done a lot faster than we're currently doing; centralized
metadata helps, but there are obviously other tricks, too -- just as an
example, look at how quickly Google Picasa can scan your whole disk for
images!

Making "svn edit" a required operation is asking for trouble, because
it's too easy to work around the requirement. The only viable option
would be to use FS change notifications on systems that support it, but
since there aren't too many of those, we shouldn't rely on such things
to get acceptable performance.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-11 09:39:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.