Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package mercurial for openSUSE:Factory 
checked in at 2026-02-01 22:01:47
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/mercurial (Old)
 and      /work/SRC/openSUSE:Factory/.mercurial.new.1995 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "mercurial"

Sun Feb  1 22:01:47 2026 rev:220 rq:1329898 version:7.2

Changes:
--------
--- /work/SRC/openSUSE:Factory/mercurial/mercurial.changes      2025-11-19 
14:54:02.396404242 +0100
+++ /work/SRC/openSUSE:Factory/.mercurial.new.1995/mercurial.changes    
2026-02-01 22:02:05.356155698 +0100
@@ -1,0 +2,288 @@
+Thu Jan 29 22:16:18 UTC 2026 - Sean Baggaley <[email protected]>
+
+- Mercurial 7.2
+
+  This is the first release to support Python 3.14 and likely the last to
+  support Python 3.9.
+
+  This release is exceptionally full of changes, and as always a lot of minor
+  changes have been omitted from these release notes.
+
+  + New Features
+    * Support for Python 3.14
+    * Added a `closesbranch()` template keyword
+    * Added support for support `--remote-hidden` in `hg incoming`
+    * `hg clone` now supports `--no-stream` to force opt-out of a streamclone
+    * `hg strip` will optionally accept empty revision sets without bailing out
+      (`--permit-empty-revset`). This is unconditionally enabled for `hg 
debugstrip`
+    * Support for ZSTD is improved by falling back to the system package if the
+      vendored module is not available. This change mostly affects pure python
+      installs and helps distributions to use their integrated version by 
default.
+      The appropriate package has been added as a Python optional dependency
+      to help people who need it.
+    * Added a new `usage.resources.bandwidth` config to tune how aggressive
+      Mercurial is with its bandwidth usage.
+
+  + Feature moved out of experimental
+    * `dirstate-v2` format (8c912a652c54)
+
+      A better format for storing the working copy information, provides a 
significant
+      performance boost to `hg status` performance (and other commands that 
need that
+      information like `commit`, `purge`, etc).
+
+      The use of `dirstate-v2` can only be recommended when using the Rust
+      extensions, as the Python version is quite slow at most operations 
(likely
+      slower than dirstate-v1).*
+
+      See `hg help config.format.use-dirstate-v2` for details.
+
+    * `diff.merge` configuration (a1c2e0753d1a)
+
+      When set, running `hg diff` on a merge will show the difference compared 
to the
+      default merge result instead of the diff against a parent. This is quite 
useful
+      to spot changes introduced by a merge and how conflicts were resolved.
+
+      See `hg help config.diff.merge` for details.
+
+    * `tracked-hint` format (bdd10cd37f6a)
+
+      A small format variant that keeps a small file that helps external 
automation to
+      detect changes to the set of tracked files.
+
+      See `hg help config.revlog.reuse-external-delta-compression` for details.
+
+    * Parallel stream clone processing (2cc0954cef52)
+
+      The parallel processing of incoming stream bundles is now enabled by 
default.
+      See `hg help config.worker.parallel-stream-bundle-processing` for 
details.
+
+  + Performance improvements for existing features
+    * `hg purge` (aka `hg clean`) now better leverages the Rust implementation 
of
+      "status" when available. This provides performance improvement similar 
to the
+      one provided by the rust status.
+    * The computation of deltas when storing a revision (during `commit`, 
`clone`,
+      `push`, `pull`, `unbundle`, ...) was significantly sped up in Mercurial 
7.2.
+      This was achieved by a mix of reducing the amount of useless work done,
+      improving the algorithms used, and smarter cache usage. All flavors of
+      Mercurial (using the Rust extensions or not) should see a performance
+      improvement, but using the Rust extensions will show a more dramatic
+      improvement (some benchmark move from almost 4 hours to 2 minutes).
+
+      (Here is small set of the involved changesets: 916d5b1db75f, 
a2cbf3d71a94,
+      2e8ba3356d7e, 4eb879393c45, 855cfc1c7c42, 2cbc32498a83)
+
+    * The performance of caches related to tags has been improved when using 
the
+      Rust extensions (f93ba6645f8e, eed40a296a18)
+    * The performance of `commit` has been improved by removing useless 
computation
+    * The performance of the Rust index (specifically the nodemap) with large
+      revlogs has been improved
+    * Warming a cold filenode tag cache is up to 12% faster
+
+  + New Experimental Features and Formats
+    + Narrow-Store's Shapes
+
+      We are introducing the concept of "shapes" to improve the experience 
using
+      `narrow`. Since using `narrow` implies using a more centralized workflow 
of
+      version control, clients being dependent on the server for all practical
+      matters of exchanging changes, we want to make this hybrid
+      centralized/distributed world more practical.
+
+      The feature is still experimental and actively worked on, but Mercurial 
7.2
+      ships some already usable parts:
+
+      * A new server-side configuration (`.hg/store/server-shapes`) to define 
shapes,
+        which are normalized and minimal descriptions of views into a slice of 
a
+        repository store based on file names
+      * A new `admin::narrow-server` command to get and list important 
information
+        about these shapes
+      * A new `admin::narrow-client` command to inspect the client state 
within this
+        workflow
+      * `hg bundle` is now able to generate streaming narrow clonebundles from 
shapes:
+          * Support for *non-streaming* narrow clonebundles is not implemented 
yet
+          * Each such bundle's bundlespec contains the fingerprint of the 
shape it was
+            generated with
+          * A client `hg` can generate the same fingerprint from the narrow 
patterns
+            passed to `clone` (`--include`, `--exclude`)
+          * This makes the client `hg` filter out bundles that do not have the
+            expected fingerprint
+          * Old clients will not receive fingerprinted bundles when listing
+            clonebundles, so backwards compatibility is conserved
+          * This process is quite manual still, but is expected to improve in 
the
+            coming versions
+
+      For more detailed information, see `hg help shapes`.
+
+    + File Index
+
+      The File Index is a new repository format that supersedes the `fncache` 
format.
+      It tracks all file paths ever used within a repository throughout its 
entire
+      history (excluding the working copy) and is useful for many common 
commands.
+      The File Index is designed for efficient querying and updating and our
+      benchmarks show significant performance improvements compared to when 
using the
+      `fncache`. This is an internal format change that doesn't affect the
+      availability of any feature.
+
+      The introduction of the File Index will also open the door for other
+      datastructures and algorithms to make use of its internal mapping of 
unique
+      file to unique token, further unlocking a ton of performance down the 
line. You
+      can learn more about its design by running `hg help 
internals.file-index`.
+
+      While basic support for the file index is implemented in Python, its use 
is
+      only recommended when using the Rust extensions for performance reasons.
+
+    + Revlog delta info
+
+      The `delta-info-revlog` format variant is a small adjustment to the 
`revlog-v1`
+      format to better keep track of some information to help speed up some 
operations
+      and improve the internal storage. This is an internal format change that 
doesn't
+      affect the availability of any feature.
+
+      The new information stored mostly focuses on:
+
+      - Does a file revision contain file rename metadata?
+      - Is a stored delta a "standard delta" or a "snapshot" (of any level)?
+      - Is the stored delta "small" and which parent is best to find such a 
"small"
+      delta?
+
+      Having this information around has various benefits:
+
+      - We no longer need to manually inspect rename metadata in any case, 
speeding up
+        various operations. This especially helps the copy tracing used by `hg 
status`
+        and `hg merge` where such checks would add up to ⅓ of the total time.
+      - We no longer need to worry about `issue6528` on delta-info repositories
+        (especially during exchanges given that `changegroup-v4` is used)
+      - Having more information about delta quality and "best parent" helps to
+        generate better bundles faster when the stored delta cannot be directly
+        reused.
+      - Having more precise snapshot information allows for more advanced 
heuristics
+        when creating the delta tree used for storage. In particular, it 
unlocks
+        skipping over redundant deltas in the parents' chain, using delta 
folding
+        heuristics. That last part requires the Rust extensions to be enabled.
+
+      Consider giving the format a try on large repositories if you experience 
slow
+      `push`/`pull`.
+
+      Some of these features are controlled by the following experimental 
features:
+      - `storage.revlog.record-delta-quality`
+      - `storage.delta-fold-estimate`
+
+    + Changegroup v4
+
+      A new changegroup format was introduced to carry the new information from
+      delta-info. The format also includes some extra features that help 
performance
+      overall:
+
+      - explicitly transfer the full revision size to avoid situations where 
the
+        client has to recompute at unbundle time
+      - explicitly carry the "has metadata" information for filelogs to avoid 
the need
+        to detect `issue6528` at unbundle time
+      - explicitly carry snapshot and quality information regarding exchanged 
delta to
+        help the client to take more informed decisions when applying incoming 
deltas
+      - explicitly carry the source delta base information to help the client 
find a
+        suitable base quicker when receiving a recomputed delta
+      - allow the exchange of deltas in their compressed form. This reduces the
+        overall efficiently of compressing the bundle stream, but avoids costs
+        associated with decompressing and recompressing the deltas on the 
server *and*
+        the client. This also helps to identify deltas that won't benefit from 
being
+        compressed to speedup their application.
+
+      This format is not used by default unless the `delta-info-revlog` format 
variant
+      is in use. It can be enabled using the `experimental.changegroup4`
+      configuration.
+
+      The various new features and behaviors associated with it can be 
controlled
+      using various configuration options:
+
+      - `storage.revlog.exchange-compressed-delta`
+      - `storage.revlog.reuse-external-delta-compression`
+      - `storage.revlog.reuse-external-suspicious-delta-parent`
+
+    + Branchmap v3
+
+      The V3 version of the branchmap is a small evolution from the V2 format 
that has
+      been used. The main difference is that the topological heads are no 
longer
+      explicitly listed in the cache. This significantly reduces the size the
+      branchmap that has to be read and written to disk and allows for various
+      optimizations when a repository update only affects topological heads on 
a
+      branch.
+
+      In particular, this new branchmap format drastically reduces the cost of
+      named-branch-related computations for large repositories that don't use 
the
+      feature.
+
+      Further performance improvements are expected with further code changes 
in later
+      versions (without affecting the format).
+
+      That feature is not enabled by default yet, don't hesitate to give it a 
try on
+      any repositories with many heads or branches you might have at hand.
+
+    + Rust Fast Path
+
+      `rhg` now supports the `purge` (aka `clean`) command, for even better
+      performance that combines with the on this command gains previously 
mentioned.
+
+  + Bug Fixes
+    * The `profiling.output-dir` now supports expansion of tilde and shell 
variables
+    * The `lfs` extension now expands and resolves the blob cache path to an
+      absolute path
+    * The availability of the given compression engine is now checked before
+      applying a clonebundle
+    * Extensions can now alter the contents of the repo's default config when 
using
+      stream clone
+    * Support for changing the process name on Linux and MacOS has been 
restored
+      (useful for `chg` users)
+    * Using `RUST_LOG` when profiling with `py-spy` will not display the logs 
of
+      `py-spy` itself anymore
+    * `hgweb` now validates that plain filesystem paths exist in `--web-conf` 
file
+      instead of raising 500
+    * subrepo: fix an error handler in `hgsubrepo.matchfileset()`
+    * largefiles: fix a MergeAction bytes vs str issue for marking a file 
removed
+    * Local access to repositories with `pull`/`incoming` and `push` now honors
+      `server.view` (note that `hg clone` in link-mode still does *not* honour
+      `server.view`, `hg clone --pull` does)
+    * repo-cache: fix using --chg with the rust extension (issue10048)
+    * update: fix crash in rust update-from-clean on certain byte sequences
+    * tracing: avoid writing traces to stdout, write to stderr instead
+    * verify: fix fncache consistency checks (fixes #10045)
+    * encoding: skip over "environ" re-encoding it the codec is bad
+
+  + Internal API Changes
+    The large and ongoing Python typing effort has once again made significant
+    progress. To that end, there was a large import-cycle-breaking series that
+    implied refactoring, new files which may make this merge more difficult for
+    extension maintainers. We're sorry about that, but typing the Python code 
is
+    helping us make the codebase a lot clearer and is now catching a lot of 
bugs
+    during development, including within common third-party extensions like
+    `tortoise-hg`.
+
+    Raw changes are listed here to help with migrating.
+
+    - 54d9dc0c2209 "cleanup: drop compatibility for `islocal(<repo-obj>)`"
+    - f2aa1bb35860 "deprecations: remove support for `HGWITHRUSTEXT` env var 
and
+      its usages"
+    - f026848bebe4 "deprecations: remove `manifest.readfast`"
+    - e915f96ea1d5 "deprecations: remove `manifest.readdelta`"
+    - ee0a7fa4cdd5 "revlog: enforce the "writable parameter""
+    - 592438265fb3 "cleanup: drop the simplestorerepo extension"
+    - 4963494bbd3f "bundle2: deprecate `bundle2.getrepocaps()` for hg 7.3"
+    - a49c8fe2c986 "branchmap: drop the `repo.branchheads` method"
+
+  + Miscellaneous
+    * Add a `commands.commit.report-head-changes` config option, to remove the 
need
+      for what can be an expensive computation in cases where it's not needed.
+    * contrib: update apache-server Dockerfile to debian:trixie
+    * Added `--py-installer` option to `run-tests.py` to control how Mercurial 
is
+      installed before tests
+    * Added an `--offline` option to `run-tests.py`
+    * Documented installation through `uv` for Rust extensions (see `hg help 
rust`)
+
+    Following the significant work made in 7.1 in this area, further changes 
have
+    been made to the way developers can create a local copy of Mercurial for
+    testing. Here are the unedited changes to make it easier to follow for 
those
+    affected:
+
+    - e2d10987bf26 "make-local: change the venv name"
+    - e53ba925c7eb "make-local: add a symbolic link hg-local"
+    - 2d69d5a333a6 "make-local: OFFLINE option"
+
+-------------------------------------------------------------------

Old:
----
  mercurial-7.1.2.tar.gz

New:
----
  mercurial-7.2.tar.gz

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ mercurial.spec ++++++
--- /var/tmp/diff_new_pack.GBOrNV/_old  2026-02-01 22:02:07.268235476 +0100
+++ /var/tmp/diff_new_pack.GBOrNV/_new  2026-02-01 22:02:07.272235643 +0100
@@ -1,7 +1,7 @@
 #
 # spec file for package mercurial
 #
-# Copyright (c) 2025 SUSE LLC and contributors
+# Copyright (c) 2026 SUSE LLC and contributors
 #
 # All modifications and additions to the file contributed by third parties
 # remain the property of their copyright owners, unless otherwise agreed
@@ -37,7 +37,7 @@
 %endif
 
 Name:           mercurial
-Version:        7.1.2
+Version:        7.2
 Release:        0
 Summary:        Scalable Distributed SCM
 License:        GPL-2.0-or-later

++++++ mercurial-7.1.2.tar.gz -> mercurial-7.2.tar.gz ++++++
/work/SRC/openSUSE:Factory/mercurial/mercurial-7.1.2.tar.gz 
/work/SRC/openSUSE:Factory/.mercurial.new.1995/mercurial-7.2.tar.gz differ: 
char 5, line 1

++++++ vendor-rust.tar.zst ++++++
/work/SRC/openSUSE:Factory/mercurial/vendor-rust.tar.zst 
/work/SRC/openSUSE:Factory/.mercurial.new.1995/vendor-rust.tar.zst differ: char 
7, line 1

Reply via email to