##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

packaging: modernize (compat PEP 517) with less distutils and setup.py calls...
packaging: modernize (compat PEP 517) with less distutils and setup.py calls - setup.py: less distutils imports and setuptools required distutils is deprecated and one should import commands from setuptools to support modern workflows depending on PEP 517 and 518. Moreover, for Python >=3.12, distutils comes from setuptools. It corresponds to old and unmaintain code that do not support PEP 517. The PEP 517 frontends (pip, build, pipx, PDM, UV, etc.) are responsible for creating a venv just for the build. The build dependencies (currently only setuptools) are specified in the pyproject.toml file. Therefore, there is no reason to support building without setuptools. Calling directly setup.py is deprecated and we have to use a PEP 517 frontend. For this commit we use pip with venv. - run-tests.py: install with pip instead of direct call of setup.py Mercurial is then built in an isolated environment. - Makefile: use venv+pip instead of setup.py
Josef 'Jeff' Sipek - - Load All Authors

File last commit:

r45111:c5653cf2 default
r53946:f5091286 tip default
Show More
TODO.md
30 lines | 1.1 KiB | text/x-minidsrc | MarkdownLexer
/ hgext / git / TODO.md
History | Annotation | Raw |Copy content |Copy permalink

Octopus Merge Support

This will be moderately complicated, as we'll need to synthesize phony
changeset entries to explode the octopus into "revisions" that only
have two parents each. For today, we can probably just do something like

aaaaaaaaaaaaaaaaaaXX{20 bytes of exploded node's hex sha}

where XX is a counter (so we could have as many as 255 parents in a
git commit - more than I think we'd ever see.) That means that we can
install some check in this extension to disallow checking out or
otherwise interacting with the aaaaaaaaaaaaaaaaaa revisions.

Interface Creation

We at least need an interface definition for changelog in core that
this extension can satisfy, and again for basicstore.

Reason About Locking

We should spend some time thinking hard about locking, especially on
.git/index etc. We're probably adequately locking the git
repository, but may not have enough locking correctness in places
where hg does locking that git isn't aware of (notably the working
copy, which I believe Git does not lock.)