"Martin Letenay" <firstname.lastname@example.org> wrote on 06/29/2005 07:56:38 AM:
> > Committed in r1418 and 1419.
> > For those that are watching, Martin meant to say he was
> > tackling the Checkout option, not commit.
> Ooops !
> My fault, of course checkout ...
> > Martin, a few questions:
> > 1) Do we still need the old Run method signature at all?
> No I don't think so.
> I thought you would know. According to my knowledge we can remove it.
If nothing else uses it, I would rather we just change the signature. If
someone else wants to use the core plugin they just have to provide a
NullProgressMonitor to the method.
> > 2) If not, then we can just change the signature, if we do
> > then how about
> > runWithMonitor() as the new method name instead of runDirectly()?
> I agree.
We should probably just stick wtih run().
> > 3) I see the progress messages, but my percentage stays at
> > 9% until the end. Do we have any options here? Ideally, we
> > could show a moderately accurate percentage, or at least one
> > that increments. If not, could we just ditch that all
> > together and just have the progress messages? I think a
> > percentage that isn't moving is not a good idea.
> Well, we for sure can increase the progress bar.
> The question I was not able to asnwer was, what is "moderately
> We know when a resource was checked-out, but we do not know how many
> resources there are ...
> It seems that the existing progress works for two things:
> - when you're checking out several resources within one command
> - to show progress of each checkout in the sense of it's 3 phases -
> scrubProject 9%, checkout 82%, refreshProject 9%.
> I don't have a sound proposal here.
> If we can have some reasonable solutions it would be fine, because this
> "steady progressbar" issue is also related
> to many other operations like synchronize/update/switch etc ...
All I can think of is picking some number to provide as an estimate to the
total number of objects, and then increment by 1. That would at least
cause the monitor to increment. Maybe there is a way that
Subversion/JavaHL could be enhanced some day to send a notification that
we could catch to use for this?
Is there a way we could start with something like 1000 and then if we
reach that number add another 100 to it? Maybe the 1000 could be a
preference? Seems like overkill though. Also, for other operations like
commit/update the 1000 would probably be way too big.
Does Eclipse provide a ProgressMonitor for the scenario where you do not
know the total?
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Wed Jun 29 22:54:10 2005