unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: David Reitter <david.reitter@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: 23 branch - can't push - lock
Date: Fri, 17 Jun 2011 18:39:59 +0300	[thread overview]
Message-ID: <83sjr8wjow.fsf@gnu.org> (raw)
In-Reply-To: <2B735F1F-756A-461D-A4D0-562AAC9BE17A@gmail.com>

> From: David Reitter <david.reitter@gmail.com>
> Date: Fri, 17 Jun 2011 09:57:43 -0400
> Cc: emacs-devel@gnu.org
> 
> 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.



  reply	other threads:[~2011-06-17 15:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 15:49 23 branch - can't push - lock David Reitter
2011-06-16 16:28 ` David Reitter
2011-06-16 21:44   ` Glenn Morris
2011-06-16 17:27 ` Eli Zaretskii
2011-06-16 17:44   ` David Reitter
2011-06-16 20:09     ` Eli Zaretskii
2011-06-17 13:57       ` David Reitter
2011-06-17 15:39         ` Eli Zaretskii [this message]
2011-06-17 19:19           ` UI / reaction time - was: " David Reitter
2011-06-17 21:59             ` chad
2011-06-19 13:42           ` Stephen J. Turnbull
2011-06-17 16:30         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83sjr8wjow.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=david.reitter@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).