Home/ Questions/Q 6656945
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T01:42:16+00:00

I’m writing a series of changegroup and commit hooks using the native Python implementation

  • 0

I’m writing a series of changegroup and commit hooks using the native Python implementation of the Mercurial API. Part of this requires me to save certain bits of information that are specific to my hooks, such as the last revision ID that my hooks actually saw.

I want to do this in a way where all external meta data is saved within the repository, but not actually tracked or ignored. I’d like to make sure this data never becomes a part of the history.

My first thought was just to use the existing .hg/hgrc configuration since I only need to store simple strings and integers, and that’s where the few configuration lines my hooks use currently live. The API provides an easy means to read this configuration via ui.config*, but it seems no means are provided to actually change or write it.

It’s easy enough for me to just get the configuration list, append or modify it then write it using a config module, but I really feel like I might be overlooking something that the API offers. I keep thinking “if there is no obvious means of doing this in a mature API, I could be going about it the wrong way.“

Is there a ‘proper’ way to do this, perhaps using the API? Or, perhaps something I haven’t found within the API to manage this sort of data without using hgrc? My chief concern is races between multiple people pushing at once.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The hgrc config files are intentional read-only and there’s no internal API to write to these files. The only exception to this rule is that clone creates a default .hg/hgrc containing the clone source URL. So, no, don’t try to use that.

    The usual way to do this sort of thing is to just read and write your own private files. Mercurial itself owns this namespace and grows its contents in an organic, backward-compatible fashion, so your best bet is to pick a subdirectory name that’s unlikely to collide with anyone else or any future Mercurial features and stash your files in there. Text-based is recommended.

    As a convenience, repo objects contain an opener method for files in the working state space (.hg/, repo.wopener()) that are protected by repo.wlock() and files in the repository store (.hg/store/, repo.sopener()) that are protected by repo.lock().

    It’s also possible to do atomic file writes:

    f = self.wopener("mydata", "w", atomictemp=True)
f.write(somedata)
f.close()

    Make sure you read this too:

    https://www.mercurial-scm.org/wiki/LockingDesign

    • 0