[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

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]