> 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.
---------------------------------------------------------------------
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 23:56:28 CEST