best way to manage local code changes which shouldn't be propagated

[Georg-W. Koltermann]

Am Donnerstag, den 15.01.2009, 19:33 +0100 schrieb Arne
Babenhauserheide:
> Am Donnerstag 15 Januar 2009 17:51:03 schrieb Georg:
> > The use case here is for local shortcuts, maybe temporary bug
> > fixes/workarounds until the owner of the respective code module comes up
> > with the proper fix, maybe disabling certain features not useful in a
> > development environment (license checks ... :-)). These I want to apply
> > only in my local environment, they should never be propagated.  Other code
> > changes which I do (deliverable code) should be propagated.
> 
> How about having an outgoing and a work repository? 
> 
> in the work repository you just use a private named branch into which you 
> regularly merge upstream changes. You do work you want to propagate in the 
> default branch and things you don't want propagated in the private branch. 

Hi Arne,

thank you very much for your fast and detailed response, but using two
repos and two branches isn't a real simplification over my previous way
with mq.

The one important fact (maybe I didn't make it clear enough) is that I
need those local changes during my development and test cycle, when I
develop public work.  

The local changes are small alterations of other parts of the code, like
disabling license checks during development and testing, or working
around deficiencies in other parts (which I'm not touching) that someone
will fix for real later, but I need a usable shortcut right now, not to
be published, not part of my own deliverable, or debug printouts
somewhere that shouldn't be included in the delivered code but I want to
have them in while working in my environment.

A second alternative (other than mq) is to exclude those files from
commit, e.g. using hgtk commit or qct commit, but all this becomes a
matter of taking additional care and manual changes, and also
uncommitted changes get into my way when merging.

Basically I'm looking for something that works as an overlay in my
source tree but doesn't get included in any commit.

If I could transparently automate this qpop -a, qpush -a around any
commit, update, merge, that would solve my problem.  Or if qpush
wouldn't create a real changeset, part of history, but instead memorize
the changes and shield them from any other hg activity.  

Hmm, maybe it's similar to the infamous line ending conversion or
keyword expansion extensions, these also "implant" alterations into the
source tree but keep them away from polluting history, I believe.

--
Regards,
Georg.