1

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.

Tim Post
  • 33,371
  • 15
  • 110
  • 174
  • 1
    I would recommend a separate file (in .hg). If you re-use the hgrc then you're using an object intended to be read-only in a read-write fashion (as you discovered) and there's no guarantee that some part of hg won't try to read the file as you are rewriting it. Additionally, that means you have to be able to correctly write all parts of the hgrc that you aren't touching... which just seems like a lot of brittle work for no gain. Using your own file in the same location gives you control and is easy without the attendant risk. – KQ. Oct 04 '11 at 16:09
  • As a note, I created the `mercurial-api` tag in order to differentiate questions that actually involve _using_ the Python API from those that don't. My hope is it will help people that hope to use the API find questions that might help them. – Tim Post Oct 04 '11 at 16:11
  • @KQ. Is there anything in the API that will help me do that? I see the same kind of race scenario setting up with or without using `hgrc`. I updated my question. – Tim Post Oct 04 '11 at 16:13
  • Not that I recall, sorry. Is the project's hgrc part of the push? If not, I don't see the race conflict, but if so, it seems like you have the downsides of parallel conflicting modifications without the assistance hg provides to handle this for normally tracked objects. I'm not familiar enough with this area to give you much help here...which is why I commented instead of answered. :-) – KQ. Oct 04 '11 at 17:46

1 Answers1

5

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

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
mpm
  • 1,935
  • 11
  • 13
  • Thank you. I think I came down with a serious case of under thinking due to chronic over thinking. I didn't realize that was possible. – Tim Post Oct 05 '11 at 10:55