Matthieu Moy <[EMAIL PROTECTED]> writes: > Michael Olson <[EMAIL PROTECTED]> writes: > >> I think I'm going to try writing an incremental parser for the >> dvc-log output. The new git-log code, in particular, feels >> unacceptably slow. > > BTW, there's another option: > > * Use git-rev-list, and parse its output. You get a skeleton ewoc > structure, and you can start displaying it (you'll get only the > "commit ..." lines. > > * Use stg like "git-show --pretty=fuller" to get the complete info > about revisions. You can divide the list of revisions into paquets > of ~10 to 50 to minimize the overhead of launching several > processes, and complete the log buffer little by little. That way, > the portion of the log which appears on screen comes more or less > immediately.
And now we have two calls to external programs rather than one, and we
are still parsing the output of the entire log message. And unless I'm
missing something, which is possible since I'm not very familiar with
ewoc, we will have to be continually seeking (either by regexp or by
text property) into the output buffer in order to place new commit
information -- my method would instead jump to a single marker without
search and start inserting output. I don't think this new option would
gain us anything.
> Indeed, we have something like this for baz, it keeps a cache (both on
> disk and in memory) of the revision information.
And I really hated the need for that "feature", because it caused a lot
of ssh instances to be run for remotely-hosted archives when getting
revision information for the first time. Some hosting sites would
simply refuse to connect after a certain number of ssh connections
within a certain timeframe, which causes cascading error messages for up
to 10 minutes.
> Before going for either approach, we should think about how to achieve
> the same results with other back-ends keeping the code well factored.
> In particular, I don't think bzr and hg have a command equivalent to
> "git rev-list" (but we can ask the user to install a plugin that
> creates one, or contribute one to upstream perhaps).
And this is precisely why this new option is suboptimal.
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
pgplAoS3MLbEh.pgp
Description: PGP signature
_______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
