Garrett Rooney <rooneg@electricjellyfish.net> writes:
> So far the primary problem seems to be speed. It's just too slow when
> working with large projects. Anyway, you can read Arthur's mail for
> the details of his complaints, but I just thought you guys might be
> interested in seeing what some competent developers think now that
> they've given us a chance.
[I've CC'd Arthur, hope he doesn't mind.]
Yup, sounds like Arthur encountered some known performance issues.
Which isn't surprising; they're exactly what we're concentrating on
right now, because they have such a big impact on users.
The checkout speed issue is already filed as:
http://subversion.tigris.org/issues/show_bug.cgi?id=1429
The commit speed issue (taking 1m22s to commit two files) might be:
http://subversion.tigris.org/issues/show_bug.cgi?id=1452
...unless the deltas involved were huge, in which case 1m22s is
perfectly reasonable. From Arthur's tone, though, I'm guessing that
the delta was not that huge :-). (But it's hard to be sure it's issue
#1452 without more information, obviously.)
The svn_load_dirs problem is unfortunate, but on the other hand, we
don't really consider the stuff in tools/ to be part of the core
product (at least as far as developer group endorsement goes!). It's
contributed stuff that we include in our distribution solely to make
things more convenient. Perhaps we need to make this clearer, though?
(It's also possible that svn_load_dirs is slow because of some
underlying problem in Subversion. If so, it would be nice to get some
demonstration of that. I don't know svn_load_dirs's algorithm, so
can't say off the top of my head.)
> I mean it isn't like these guys are clueless newbies who haven't been
> able to figure out the tool, the've got some serious issues, and try
> as I might, I can't blame them for being upset.
Nope, I can't blame him either.
Arthur, you should probably just try again in a few months, or watch
those specific issues. If you can help verify that your commit
slowness is indeed issue #1452, that would be great, but will
understand if you're too busy.
Hope to see you again -- and happier next time.
-Karl
> From: Arthur Bergman <arthur@fotango.com>
> Subject: Subversion
> To: ponie-dev@perl.org
> Date: Thu, 31 Jul 2003 14:36:29 +0100
>
> Hi,
>
> I think I can conclude my attempt to use subversion as
> ____ __ __ _ _ ____ _ _ ____ _ __ ____
> / ___| \ \ / / | \ | | / ___| | | | | / ___| | |/ / / ___|
> \___ \ \ \ / / | \| | \___ \ | | | | | | | ' / \___ \
> ___) | \ V / | |\ | ___) | | |_| | | |___ | . \ ___) |
> |____/ \_/ |_| \_| |____/ \___/ \____| |_|\_\ |____/
>
> (SUBVERSION SUCKS)
>
> First of all, checking out parrot using subversion takes at least 4
> time slonger than CVS
>
> Doing a vendor checkin brining up parrot to latest version is a major
> pain the arse. The process alone of running svn_load_dirs takes around
> an hour, and then I have to tag it (because if you tell svn_load_dirs
> to tag things automatically it breaks). It also seems not to have
> changed some stuff when other stuff has changed!
> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is
> one file that should have been updated).
>
> Committing two files took 1 minute 22 second yesterday, a checkout is
> extremely painfully slow. I am very close to saying it is a failed
> experiment and either go to p4 or cvs for the time being.
>
> A very angry Arthur who has spent far too much time battling an
> substandard versioning system. (which might be theoretically very
> nice, but does not scale)
>
>
> ps. And off I go to try and do another merge of parrot!
> ----------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 31 18:58:33 2003