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.
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.