Add build step to build chg binary #25
Conversation
This is much faster when starting hg repeatedly for short commands, which is what Chorus does a lot.
Python 3.12.5 and later produce an error when building this specific version of Mercurial, probably due to a name conflict. Rather than track it down, we can safely build with 3.12.4.
Python 3.13.0-beta.4 and later produce an error when building this specific version of Mercurial, probably the same one that Python 3.12.5 fails with. It should be safe to build Python 3.13 versions with beta.3.
Only the hg and chg binaries should actually be executable.
The various .so files have changed as well because they were last build six months ago, with different Python patch releases. But the source is the same as the build from six months ago, so no .py files have changed.
|
I have locally tested the NuGet package that this will build, and using |
|
It also shaves about 13% off the time to do CrdtMerge. A CrdtMerge of the sena-3 project when it doesn't exist locally yet (meaning it requires a S/R clone, a CRDT sync, then a regular S/R) goes from 48.6 seconds with hg to 41.9 seconds with chg. Not the spectacular improvement I was hoping to get, because there's a lot going on besides Mercurial startup times, but still a nice solid gain. |
|
This look like a good change, it looks like the most recent run of the "Build Mercurial" workflow has failed, so I'd like to see that pass. In addition I'd like that workflow to run on every PR (can exclude windows specific changes if you would like) so that running that workflow isn't a manual step. |
Instead of running the "Build Mercurial" workflow manually, we will now run its process on every PR merged to master. That will cause less confusion in the GHA actions log.
chgis much faster thanhgwhen starting Mercurial repeatedly for short commands, which is what Chorus does a lot.Fixes #24.