The problem is the -f flag. You just want to pass the filename. -f expects
an html page that it can scan links from.
You'll also need to make sure you grab the latest Djblets.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://w
I'm trying to use instructions in documentation for grabbing a nightly
(yes I know my fix won't be ready till later :) but I cannot get it to
work. Any suggestions?
Here is relavent debug output from easy_install:
$ sudo easy_install -v -n -f http://www.review-board.org/downloads/nightlies/
Revie
Great, thanks! I will test as soon as I can.
It's probable we may still have some lesser perf issues remaining even
with this fix because it's a common enough use case here for folks to
create comments on many, many different lines of codes in the same
review. This should I hope bring the load ti
Thanks for the detailed information. I had originally thought this was an
issue browser-side with too much content in the DOM, but it's load times of
fragments.
I have a patch up for review (http://reviews.review-board.org/r/757/) that
you can test. I'll be testing it a bit more and then committin
More info regarding question #3:
The performance problem is reproducable by creating comments on
multiple different line numbers of the diff. Each line diff comment
results in a seperate HTTPS GET request when the page is loaded. These
are what the GET requests look like (in FireBug):
Firebug's
Results for question #3:
I createed a reviewrequest with just one review with many comments and
it does not have the same performance issues. Additionally, in FireBug
the review is only showing one HTTPS GET request. In this test all the
comments and the review itself was made by just one user (m
Results for question #2:
I installed FireBug and setup the console to show logging. I then
brought up one of the reviews that has been a problem for us and
showed hundreds of HTTPS GET requests for diff comments, each taking
about ~200-300 milliseconds. It took ~6 minutes to fully load the
page.
Thanks for the quick response. I'll be interested in seeing the results.
I'm working on code now that should address these issues (though some
further decisions will be made based on #2 and #3).
Essentially, we're looking at expanding/collapsing reviews based on the
following logic:
For each rev
answers inline below...
On Mar 6, 3:52 pm, Christian Hammond wrote:
> A couple more questions. I'm playing around with a couple possible fixes,
> but need to find out more where the bottleneck is. Clearly it's
> browser-side, but the question is whether it's the fact that there's a lot
> in the
A couple more questions. I'm playing around with a couple possible fixes,
but need to find out more where the bottleneck is. Clearly it's
browser-side, but the question is whether it's the fact that there's a lot
in the DOM or whether the rendering is the slow part.
1) Is the page still slow once
Thank-you for making this a priority! I'll keep an eye out for the fix
and grab immediately.
Breaking up the reviews into smaller pieces is not a use case that is
going down well here, but it is known. thanks again!
On Mar 6, 2:54 pm, Christian Hammond wrote:
> We'd have to decide what we're do
When you hit this problem with large numbers of comments, how many reviews
are they usually spread across? Solving the problem of large numbers of
comments across multiple reviews is very different from large numbers of
comments on one review.
Christian
--
Christian Hammond - chip...@chipx86.com
We'd have to decide what we're doing to fix this first. Depending on what
that is, it could take a few days to implement, or longer. We can make it a
priority for beta 1 (the next release), and of course you'd be able to just
upgrade to a nightly once it's in.
Short-term, I'd just advise splitting
Yes, I mean comments not reviews.
I'm seeing the same issues on Alpha4 on my test server. It seems to me
that the loading of the diff fragments across all the comments is
causing our problems - loading such a review sometimes crashes the
browser (i've seen this on firefox mostly) and in IE the pa
I think we should. The thing is that the newest review request is at the
bottom, so it's kinda weird.
Another thing we should look into is auto-collapsing old reviews (such as
reviews made before the last update to the review request), allowing them to
expand again. This would fetch the collapsed
Perhaps we need to paginate the reviews page in addition to the diff?
-David
On Fri, Mar 6, 2009 at 2:03 PM, mary wrote:
>
> Thank you for your reply. The slowness is:
> 1. page load takes several minutes (the more comments, the longer it
> takes)
> 2. typing a comment is very slow on reviews w
Thank you for your reply. The slowness is:
1. page load takes several minutes (the more comments, the longer it
takes)
2. typing a comment is very slow on reviews with many comments.
3. Scrolling on the review page is painful when many reviews
Developers are speculating its due to a huge DOM and s
It's important to find out what's causing the slowdown. What part is being
slow? The page itself, or the progressive diffs inside of it? Alpha 1
doesn't have progressive diffs so it will be slower than alpha 4 in this
regard.
We have some large review requests like this at VMware too, and haven't
I was able to roll back to Alpha1 but ReviewBoard displayed the same
problem... an unresponsive/seriously slow GUI for reviews with 150+
comments. I also upgrade to Alpha4 with the same results.
Our company cannot use ReviewBoard with this serious performance
handicap.
We've been very happy with
Thanks for the information, I will try it on my test server (and yes,
I will keep in mind DB changes for future).
I've also been having a hard time reproducing the issues that many are
reporting but I will continue to try and gather information. The
problems are being reported using both IE7 and
In theory, you should be able to just install the 1.0alpha1 eggs of both
Review Board and Djblets. This is completely untested and unsupported,
though. Note that in the future, you'll have a harder time with this. There
were no database schema changes between alpha 1 and 4 (to my knowledge), but
t
21 matches
Mail list logo