A hacker's view of .hg

[Bob Hood]

Hi, Arne.

Thanks for the suggestion.  I'd entirely forgotten about the command server.

There are, however, a few issues I can see with that in this particular approach:

#1. I'd have to know if the command server was even running to begin with (I 
can't control the environment of an arbitrary user).  Sure, I could try the 
connection, and then fall back to the straight "hg.exe" interfacing, but the 
overhead of just checking for the command server, and then interacting with it 
to get the information I need (assuming I can), would probably prove to be 
just as much overhead in terms of CPU cycles.

#2. From what I can tell (and I may be wrong; I'd have to research it), the 
system in Cmder doesn't maintain state.  If that's the case, then I'd have to 
go through the steps in #1 above each time the prompt is generated, which is 
every time a command completes, or even every time the Enter key is pressed.  
Again, might be exchanging one overhead for another.

#3. If the command server doesn't maintain state on any given working copy, it 
too would probably just execute the same code as the "hg id" command (or 
similar), leading to the same performance overhead -- /in addition to/ all the 
testing/access stuff listed above.

I would think that reading files/state directly out of the .hg folder (if it's 
there) would be the fastest and most efficient means.


On 7/7/2018 4:51 PM, Arne Babenhauserheide wrote:
> Hi Bob, Bob Hood <bhood2 at comcast.net> writes:
>> This reduced the huge time overhead down to about 1 second on my repository. 
> You might benefit from interfacing with the Mercurial command-server: 
> https://www.mercurial-scm.org/wiki/CommandServer Best wishes, Arne -- 
> Unpolitisch sein heißt politisch sein ohne es zu merken

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20180707/5f4f3a69/attachment-0002.html>