-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Now that it's been incorporated into the nuget-ci-cd.yml workflow, there's no more need for the build-hg.yml to be a separate workflow. Having just one single workflow makes the GitHub Actions logs eaiser to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. I am a little confused why we need to build for so many python versions, but that's what we were doing before so I don't want to block this PR on that alone
chg
is much faster thanhg
when starting Mercurial repeatedly for short commands, which is what Chorus does a lot.Fixes #24.