This mail is an automated notification from the bugs tracker
of the project: xtla.el.
/**************************************************************************/
[bugs #905] Latest Modifications:
Changes by:
Matthieu MOY <[EMAIL PROTECTED]>
'Date:
Fri 10/15/2004 at 14:13 (Europe/Paris)
What | Removed | Added
---------------------------------------------------------------------------
Planned Release | 1.0 | 1.1
------------------ Additional Follow-up Comments ----------------------------
That's more complex than it seem to. Most of the job is already done
asynchronously.
For most commands displaying revision lists, I actually don't get the
information from the output of the command, but only the list of patches (this
is the case for tla missing and tla logs).
The information are taken from the log files themselves. This should be faster
for a remote archive since the log file is kept in the ~/.arch-log-library.
There are a few performance issues with the current implementation. I suspect
Emacs spends most of its time parsing log files, whereas it would be easy to
cache revision structures instead of log files, for example. The parsing of log
buffers could probably be greatly optimized too.
I planned to do those optimizations after the 1.0 release. I'm setting the
planned release to 1.1. No objection if someone wants to do this before, off
course.
/**************************************************************************/
[bugs #905] Full Item Snapshot:
URL: <http://gna.org/bugs/?func=detailitem&item_id=905>
Project: xtla.el
Submitted by: Robert Widhopf-Fenk
On: Thu 10/14/2004 at 21:29
Category: xtla.el
Priority: 1 - Later
Resolution: None
Assigned to: None
Originator Email:
Status: Open
Planned Release: 1.1
Type of request: small feature
Merge available: No
merge request:
Fixed Release:
Test case in xtla-tests.el:
Summary: Revisions and Logs should be generated asynchronously
Original Submission: It is really a pain when viewing the revisions/logs for
a version which has many of them since Emacs gets
locked for minutes and no other editing is prossible anymore.
It should be done iteratively/asynchronously, since when
calling tla from the commandline I get then piece per piece
and usually one of the last few ones is the one I am
interested in, i.e. the one of which I want to see the
change-set. Thus while the list of revisions is not
complete I may already start viewing a changset.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Fri 10/15/2004 at 14:13 By: Matthieu MOY <moy>
That's more complex than it seem to. Most of the job is already done
asynchronously.
For most commands displaying revision lists, I actually don't get the
information from the output of the command, but only the list of patches (this
is the case for tla missing and tla logs).
The information are taken from the log files themselves. This should be faster
for a remote archive since the log file is kept in the ~/.arch-log-library.
There are a few performance issues with the current implementation. I suspect
Emacs spends most of its time parsing log files, whereas it would be easy to
cache revision structures instead of log files, for example. The parsing of log
buffers could probably be greatly optimized too.
I planned to do those optimizations after the 1.0 release. I'm setting the
planned release to 1.1. No objection if someone wants to do this before, off
course.
For detailed info, follow this link:
<http://gna.org/bugs/?func=detailitem&item_id=905>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
