Michael Olson <[EMAIL PROTECTED]> writes: > 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
Likely to be true, yes. I don't know ewoc enough either. > -- 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. I'm not worried about the result of your solution, but about the implementation effort. The advantage of this solution is that it keeps the current process-management. But it's not necessarily better, that was just an idea. >> 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. The problem was different for baz/tla. We needed some ancestry information that wasn't provided on the command-line, so we _had_ to call a command (cat-log IIRC) for each revision. And the problem was that we couldn't group the calls to cat-log (like "tla cat-log rev1 rev2 rev3 ..."). Indeed, I had implemented a fix for that (baz log --complete-log), but the Bazaar team decided to throw my code away instead of ever releasing baz 1.5 :-(. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
