Best way to keep proprietary changes local

[Tony Mechelynck]

On 16/11/12 22:15, Stephen Rasku wrote:
> What is the best way to keep proprietary changes local.  I have a
> development environment that I have on bitbucket.  I have to make local
> changes for the company I am working for and I don't want to push those
> changes.
>
> What I planned to do was to create a local anonymous branch with the
> local changes and merge the generic changes in periodically.  I just
> realized that if I merge I won't have multiple heads and it will happily
> push the merged code without warning.  I can avoid this if I specify the
> revision before the merge but I want something more automatic.  The
> local changes are trivial so I don't really want a heavyweight solution.
>
> I suppose I could have a separate clone where I run the environment and
> merge the local changes and another one where I make my generic changes.
>   Another option is to use mq and pop my local changes before I push to
> bitbucket.  Any ideas?  I would like it to be as automatic as possible.
>
> ...Stephen

To keep some changes local, keep them in a clone which may pull from the 
public repository but will never push to it.

The pull may be automated by means of the fetch extension, which adds a 
new "fetch" command to the repository where it is enabled. With fetch 
enabled, "hg fetch" means:
	- "hg pull -u" if there no unnamed head in the same branch that is on 
local and not on remote
	- "hg pull" followed by "hg merge" if there is exactly one such unnamed 
head.

As long as your local changes don't conflict with changes made on the 
public repository, the merge will succeed with no problem. Of course, if 
there _is_ a conflict you will have to resolve it manually.

If you want collaborative development on some changes which will be 
pushed to the public repository and on some which won't, I can see two 
ways to do it:

(a) have just one "private" clone as above, but since you don't want to 
push from it, when you want some change to appear on the public 
repository you will have to export it as a patch, and import it on the 
public repository. It will probably get a different Changeset ID on the 
public repository since it will be reapplied there as a new patch, 
possibly with a different parent changeset.

(b) have a "private" clone as above, and a "public" clone which may push 
and pull. Anything which will become "public" gets developed on the 
"public" clone. You may then decide whether the private clone pulls from 
your "public" clone or from the "official" repository maintained by 
someone else. Your private clone still cannot push to anything where you 
don't want your private changes to appear, and in particular it cannot 
push to your public clone (or be pulled from your public clone, which 
amounts to the same thing) because that would ultimately push your 
private changes to public, which is what you don't want.

I recommend (b) because IMHO it is "cleaner": you don't risk the merge 
conflicts which you might get in (a) when you pull a repository state 
containing a changeset which you previously exported as a patch. You may 
still use (a) and keep it clean if your "patches to be made public" are 
developed by means of the mq extension, and kept in qpop state except, 
temporarily, when you're working on them.


Best regards,
Tony.
-- 
If the weather is extremely bad, church attendance will be down.  If
the weather is extremely good, church attendance will be down.  If the
bulletin covers are in short supply, however, church attendance will
exceed all expectations.
		-- Reverend Chichester