Ben Reser <ben@reser.org> wrote on 10/04/2004 10:42:52 PM:
> On Mon, Oct 04, 2004 at 08:47:33PM -0400, Mark Phippard wrote:
> > Yes, it is "that bad". Read what Tobias posted when he began this
thread:
> >
> > -- quote
> > The security fixes introduced in 1.0.8 and 1.1.0-rc4 made RA->get_dir
> > (and therefore "svn ls") over ra_dav "glacially slow" (as someone
> > described it on users@). For a simple test case of mine, an ls of 412
> > files that used to take 1.5 s now took around six minutes, i.e. it's
240
> > times slower, but it could be a lot slower still depending on the
> > circumstances. This is a showstopper performance regression for many
> > users.
> > -- end quote
>
> Well what he said is a long way from calling the software unusable.
> Yeah 6 minutes sucks. But if not many users are affected it's not as
> big of a deal. However, it sounds like TSVN makes more use of the ls
> command than command line client users do.
I assume it would effect all of the GUI's as they are all likely to make
use of ls.
Also, presumably it would effect a DAV client.
> > Why did 1.1 "get out"? Well, how long was RC4 soaked?
>
> 1 week as per HACKING.
>
> > Also, when RC4 was created it was well known that 1.1 release was
> > coming soon. So "users", like myself, just waited for the release.
>
> Well just waiting is a good way of ensuring that bugs that are
> exceedingly annoying to you end up getting in a release. A lot of us
> use the software, but most of the developers don't really use the ls
> command. Not trying to lay blame here. Just pointing out that if we're
> going to shorten the soak time (which we did becasue many people felt a
> month was too long), users who care about having clean releases need to
> be proactive in testing the release for features that matter to them.
Fair enough, but RC3 had just been released with a lot of changes, and I
was
banging away on it. RC4 came out kind of unexpectedly for me as I am not
on
the security list. The security fix did not effect me and the description
of
the change made it sound fairly benign. Couple that with the fact that
RC3 had
just been released and 1.1 was coming soon, and it just didn't seem worth
the effort
to grab it. It sounds like you were aware of the performance problem
anyway
so it doesn't seem likely it would have delayed the release.
> Faulty is a bit strong. Overzealous is more correct. It does indeed do
> what it was intended to. But it went too far. Some of that can
> probably be attributed to a *LOT* of discussion about exactly what the
> code ought to or ought not be protecting. There were some people that
> felt the author and date should be protected as well. If the policy had
> been decided that way the patch would have had a performance regression
> that couldn't be resolved.
>
> > Personally, I have no objection to a 2 week wait for a 1.1.1, but it
> > would be nice to see some "momentum" pick up around organizing that
> > release. That is, assuming the reason to wait is to get some other
> > patches into the release, perhaps some kind of call to start
> > nominating those patches could begin soon so that you have time to
> > gather the necessary review and votes in STATUS?
>
> Well the biggest thing that needs to be done is someone needs to go
> through the issue tracker and milestone the issues for the 1.1.1
> release. Usually one of the Chicago guys does that. But I think
> they're busy doing other things. So someone else probably needs to
> pickup the ball. Unfortunately, I'm also somewhat busy right now.
>
> As far as the 1.0.9 release, we need to get people to move on reviewing
> the patch. I suppose I'll have to set a date and chase people to bother
> to review it if nobody does by the time the day for the release comes
> up.
Thanks for the detailed reply. It all sounds very reasonable.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 5 15:00:46 2004