Development / Production Recommended Workflow?

Steve Fink sphink at gmail.com
Thu Aug 19 14:33:03 UTC 2021


In a similar situation, I split my config files into published and
unpublished portions. The main, unpublished config file has an include
directive pulling in the published config file, which contains settings
that are common between development and production.

Often, I don't bother to version-control the unpublished config files.
But when I do, I use a separate repository that I symlink to. So:

main/
    shared-config.py
    config.py (symlink to ../configs/production.py)
    ...code...
    .hg/

configs/
    production.py
    staging.py
    dev1.py
    dev2.py
    .hg/


where `production.py` has some settings plus a directive `include
"shared-config.py"`.

This setup requires some sort of include directive. Or something
similar: for my personal hgrc file, I have a published file at
`https://hg.sr.ht/~sfink/sfink-tools/browse/conf/hgrc?rev=tip` (that I
symlink to from ~/.hgrc) that omits keys and passwords and other
personal configuration, and then I put the private stuff in
`~/.config/hg/hgrc`. As far as I know, there are no include directives
in hgrc files, but there is a list of paths that it will load so you can
use one of them for the published stuff and another for the unpublished.

This may not cover everything you need, but I would definitely use
*some* setup to avoid shipping around patch files. It would make me
nervous. It feels like it provides too many opportunities for subtle
mistakes that would be hard to track down afterwards.

Committing database snapshots with the code feels off to me too, but I
don't personally have a good workflow around those so I won't comment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20210819/be0f7487/attachment-0002.html>


More information about the Mercurial mailing list