[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23 branch - can't push - lock
From: |
Eli Zaretskii |
Subject: |
Re: 23 branch - can't push - lock |
Date: |
Fri, 17 Jun 2011 18:39:59 +0300 |
> From: David Reitter <address@hidden>
> Date: Fri, 17 Jun 2011 09:57:43 -0400
> Cc: address@hidden
>
> On Jun 16, 2011, at 4:09 PM, Eli Zaretskii wrote:
> >> First page only:
> >> real 0m3.594s [faster when repeated,i.e., in cache]
> >
> > What kind of machine is that? On my 6-year-old Windows box with a
> > single 3 GHz core, I get this:
>
> Core i7, 2.6GHz, 4GB RAM.
Strange. It should be faster than mine.
> > And anyway, 3.5 sec is hardly significantly different from 0.8, for
> > producing something that a human needs to _read_.
>
> Actually, I disagree.
If you see 3.5 sec as a significant delay, I wonder what's your
opinion about GCC compiling Emacs sources. And in case of "bzr log"
the results need to be read by you, which will certainly take more
than just 3 seconds.
> A modern interface should not make the user wait that long - I would estimate
> anything beyond 30ms is discernible
How do you mean "discernible"? Most humans are generally unable to
react in less than 200-300ms, so 30ms is an order of magnitude off the
mark.
> and anything beyond 1s may be seen as interrupting someone's workflow.
Typing a command takes more than 1s, so I guess your workflow is being
interrupted all the time, and you are used to it anyway ;-)
> At some point, people (perhaps including you) did an awesome job making Emacs
> start up fast.
I only start my Emacs once in several weeks, so the startup (which is
quite long, actually, because my sessions visit a lot of files)
doesn't bother me more than the time it takes the entire machine to
come up.
> Just getting the first pages of a log should happen instantly
Well, it takes less than 1s here, which is instant enough for me.
> I'd find the timing you get acceptable, but mine is just sluggish.
You should investigate the reasons for that sluggishness, then.
> I started out with the wrong command, "bzr merge -c 104024", because I
> thought that the revision ID is unique (sorry, Git thinking). It took 65
> seconds to give me an error message!
How about submitting a bug report (https://bugs.launchpad.net/bzr)
about that?
> And the wording of the error message wasn't even very user-level:
>
> InvalidRevisionSpec: Requested revision: u'104024' does not exist in branch:
> BzrBranch7('file:///Users/dr/Projects/emacs/emacs-23/')
Is that what was displayed on the screen, or is it from .bzr.log? The
latter is not only for users, so I would tolerate some technicalities
there for the sake of technical information the developers will want
to know.
> I updated Bazaar after that to 2.3.1, and did the same merge a second time
> (this one may be much easier for Bzr now - I don't know).
> It still took 20 seconds. That's sluggish in my book.
Most of my merges take less than 5 sec, but some took 20 or 30s. I
don't consider that to be sluggish, but if you don't mind to live on
the edge, try the latest beta of bzr 2.4, I understand that "merge"
got a significant speedup there.
> Is there a way to reset a branch to a previous commit, i.e., the equivalent
> of "git reset --hard"?
That's git talk, and I don't really know what it means. If you want
to be able to re-apply the same merge, I think you want "bzr
uncommit". (But don't try that with a bound branch!) Alternatively,
make a new branch from the revision before the merge, and then merge
onto that.