I have the same situation: Local configuration that I want to prevent from propagating, but I want to be able to push and pull the same files. Instead of messing with patches, I've been doing it as follows:
Let's say the regular takes place in branch default
(there could be multiple branches; this is just for concreteness).
- Update to a clean latest version of
default
, without config state.
- Create a new branch,
local
. In this branch, commit all the local configuration as one or more changesets.
At the tip of local
, create a new branch, dev
. Develop your new feature here.
Your history now looks like this:
...o--o (default)
\
L--L (local)
\
d--d--d (dev)
When you're ready to push, rebase the entire dev
branch onto the tip of default
:
hg rebase --source "min(branch('dev'))" --dest default --detach
If your feature has its own branch name that you want to keep, add --keepbranches
to the rebase
options. The previous tree becomes:
...o--o--d--d--d (default)
\
L--L (local)
You can now publish the new features with push -r default
without dragging along the local revisions. (Never merge from local
into default
; only the other way around). If you forget to say -r default
when pushing, no problem: Your push gets rejected since it would add a new head.
Still on the development server, merge the rebased revs into local
:
...o--o--d--d--d (default)
\ \
L--L-----N (local)
You can now create a new dev
branch on top of local
, and continue development.
This way my local configuration is under source contol; if it conflicts with a new feature, I can resolve it like any other merge. And if something should go wrong, I can update back to configured older versions.
My case also involves configured clones under revision management. You can see the full solution in this answer.