Mercurial

changeset 331a3cbe1c9e branch bookmark ... [More] tag user Georges Racinet description rustdoc: fixed warnings about links This is the minimal fix making those that actually were supposed to be links to work (including in private items). files rust/hg-core/src/checkexec.rsrust/hg-core/src/revlog/nodemap.rsrust/hg-core/src/utils.rsrust/hg-core/src/utils/hg_path.rs [Less]

changeset f0d2b18f0274 branch bookmark ... [More] tag user pacien description stabletailgraph: implement stable-tail sort This adds the computation of the "stable-tail sort", an incremental node sorting method. It is a stepping stone for the implementation of faster label discovery (for example for obs markers) and more caching. files mercurial/debugcommands.pymercurial/stabletailgraph/__init__.pymercurial/stabletailgraph/stabletailsort.pysetup.pytests/test-completion.ttests/test-help.ttests/test-stabletailgraph.t [Less]

changeset 071a6c1d291e branch default bookmark @ ... [More] tag tip user Georges Racinet description rust-changelog: introduce ChangelogEntry parent entries accessors Straightforwards now that lifetimes are explicit in `RevlogEntry` parent accessors. files rust/hg-core/src/revlog/changelog.rs [Less]

changeset 071a6c1d291e branch bookmark ... [More] tag user Georges Racinet description rust-changelog: introduce ChangelogEntry parent entries accessors Straightforwards now that lifetimes are explicit in `RevlogEntry` parent accessors. files rust/hg-core/src/revlog/changelog.rs [Less]

changeset c101e7757ed7 branch bookmark ... [More] tag user Georges Racinet description rust-revlog: fix lifetime problem for RevlogEntry parent entries accessors Without this, the lifetime of the result is equated to the lifetime of the `self` reference, preventing callers, e.g., to take a `RevlogEntry` and return its `p1_entry()`, as it looks like returning something that does not outlive the *reference to* the `RevlogEntry`. files rust/hg-core/src/revlog/mod.rs [Less]

changeset 7ef51fff2c4f branch bookmark ... [More] tag user Georges Racinet description rust-revlog: explicit naming for `RevlogEntry` lifetime This matches what has been done in `revlog::changelog::ChangelogRevisionData`, and has the advantage of making things clearer when we introduce other, shorter lived lifetimes. files rust/hg-core/src/revlog/mod.rs [Less]

changeset b5dd6d6d6fa6 branch bookmark ... [More] tag user Georges Racinet description rust-changelog: added a test for `NULL_REVISION` special case The result is due to `Revlog.get_rev_data()` returning an empty byte string for `NULL_REVISION`, followed by special case for emtpty byte strings in `ChangelogRevisionData::new()`. files rust/hg-core/src/revlog/changelog.rs [Less]

changeset 841b13e6e84c branch bookmark ... [More] tag user Georges Racinet description rust-changelog: introducing an intermediate `ChangelogEntry` Before this change, client code needing to extract, e.g, the Node ID and the description from a changeset had no other choice than calling both `entry_for_rev()` and `data_for_rev()`. This duplicates some (limited) computation, and more importantly imposes bad hygiene for client code: at some point of developement, the client code would have to pass over both entry and data in its internal layers, which at some point of development would raise the question whether they are consistent. We introduce the intermediate `ChangelogEntry` from which both conversion to the generic `RevlogEntry` and extraction of `ChangelogRevisionData` are possible. It might grow some convenience methods in the future. We keep the `data_for_rev()` method of `Changelog` for compatibility, pointing users at the more powerful alternative. files rust/hg-core/src/revlog/changelog.rs [Less]

changeset b47a9316050a branch bookmark ... [More] tag user Georges Racinet description rust-changelog: made doc-comments more consistent The most important is the one about `data_for_rev`, that looked like a copy-paste leftover (got me confused first time I read this code, before I actually learned there were both `Entry` and RevisionData`. In the comment for the `struct`, "changelog" was probably more about the format in general (as documented elsewhere) than as an identifier. Some of the "Return something" had "of", half had "for". files rust/hg-core/src/revlog/changelog.rs [Less]

changeset cf4d2f31660d branch stable bookmark ... [More] tag user Arun Kulshreshtha description chg: populate CHGHG if not set Normally, chg determines which `hg` executable to use by first consulting the `$CHGHG` and `$HG` environment variables, and if neither are present defaults to the `hg` found in the user's `$PATH`. If built with the `HGPATHREL` compiler flag, chg will instead assume that there exists an `hg` executable in the same directory as the `chg` binary and attempt to use that. This can cause problems in situations where there are multiple actively-used Mercurial installations on the same system. When a `chg` client connects to a running command server, the server process performs some basic validation to determine whether a new command server needs to be spawned. These checks include things like checking certain "sensitive" environment variables and config sections, as well as checking whether the mtime of the extensions, hg's `__version__.py` module, and the Python interpreter have changed. Crucially, the command server doesn't explicitly check whether the executable it is running from matches the executable that the `chg` client would have otherwise invoked had there been no existing command server process. Without `HGPATHREL`, this still gets implicitly checked during the validation step, because the only way to specify an alternate hg executable (apart from `$PATH`) is via the `$CHGHG` and `$HG` environment variables, both of which are checked. With `HGPATHREL`, however, the command server has no way of knowing which hg executable the client would have run. This means that a client located at `/version_B/bin/chg` will happily connect to a command server running `/version_A/bin/hg` instead of `/version_B/bin/hg` as expected. A simple solution is to have the client set `$CHGHG` itself, which then allows the command server's environment validation to work as intended. I have tested this manually using two locally built hg installations and it seems to work with no ill effects. That said, I'm not sure how to write an automated test for this since the `chg` available to the tests isn't even built with the `HGPATHREL` compiler flag to begin with. files contrib/chg/chg.c [Less]