[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: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 11 Apr 2008 16:22:36 -0700

On Fri, Apr 11, 2008 at 3:15 PM, Listman <listman_at_burble.net> wrote:
>
>
> On Apr 11, 2008, at 3:05 PM- Apr 11, 2008, David Glasser wrote:
>
>
> > On Fri, Apr 11, 2008 at 2:56 PM, Listman <listman_at_burble.net> 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. ;-)
> > > >
> > > >
> > > > 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'd agree with this. I can't understand how anyone would see "adequate"
> svn
> > > performance when the repository gets large (read 10's of 1000's of
> files).
> > >
> > > Note that "warming the cache" 90% of the time doesn't help - my company
> has
> > > ~ 50
> > > users and the cache quickly gets out of date..
> > >
> > > we also have perforce here and i thought you'd be interested in seeing a
> > > comparison.
> > >
> > >
> > > for a 505MB working copy with 36,781 objects
> > >
> > > comparing Subversion and Perforce:
> > >
> > > SUBVERSION
> > > [cad_at_x09 /home/cad/trials/svn/work] -57- % time svn status
> > > ? fab7
> > > 1.614u 5.141s 5:09.28 2.1% 0+0k 0+0io 8pf+0w
> > >
> > >
> > > PERFORCE
> > > [cad_at_x09 /home/cad/trials/versic/p4/work] -78- % time p4 opened ...
> > > ... - file(s) not opened on this client.
> > > 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
> > >
> > > [sbutler_at_x07 /home/sbutler/trials/p4/work] -70- % time p4 sync
> > > File(s) up-to-date.
> > > 0.000u 0.000s 0:00.14 0.0% 0+0k 0+0io 0pf+0w
> > >
> > >
> > > so subversion took 5:09min to report back and p4 less than a second.
> > >
> > >
> > > NOTE that svn update is very slow also.
> > >
> >
> > Perforce and Subversion have different scaling characteristics. Some
> > situations work better for Perforce; some work better for Subversion;
> > others would work better for Subversion if the wc was improved.
> >
> >
>
> for a "typical" company with say 100 users on a fast local network with
> user accounts on a netapp fileserver, what are the scaling benefits of
> Subversion?

At this point I think we've moved from dev@ topics to users@ topics.

(My svn performance goals are aimed at repositories with quite a bit
more than 100 users.)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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-12 01:22:51 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.