Merging changes to a workspace with uncommitted changes

Question

We've just recently switched over from SVN to Mercurial, but now we are running into problems with our workflow. Example: I have my local clone of the repository which I work on. I'm making some highly experimental changes to our code base, something that I don't want to commit before I'm sure it works the way it is supposed to, I don't want to commit it even locally. Now, simultaneously, my co-worker has made some significant improvements/bug fixes which I need. He pushes his commits to our main repository. The question is, how can I merge his changes to my workspace without the requirement that I have to commit all my changes, since I need his changes to test my own code?

A more day-to-day problem we have with the exact same workflow is where we have a couple of configuration files which are in the repository. Each developer makes a couple of small environment specific changes to the configuration files, but do not commit the changes. These couple of uncommitted files hinders us from making any merges to our workspace, just like with the example above. Ideally, the configuration files probably shouldn't be in the repository, unfortunately, that's just how it has to be for here unnamed reasons.

Answer 1

Regarding your experimental changes, you should commit them. Often. Simply you commit them in a clone you don't push. You only pull to merge whatever updates you need from other repos.

As for config files, don't commit them.
Commit template files, and script able to generate complete config files from the template.
That way, developers will only modify "private" (i.e. not committed) config files with their own private values.

Answer 2

There are two operations, as you've discovered, that makes changes from one person available to someone else (or many, on either side.)

There's pulling, which takes changes from some other clone of the repository and puts them into your clone.

There's pushing, which takes changes from your repository and puts them into another clone.

In your case, your coworker has pushed his changes into what I assume is your central master of the repository.

After he has done this, you can pull the latest changes down into your repository, and merge them into your branch. This will incorporate any bugfixes or changes your coworker did into your experimental code.

This gives you the freedom of staying current on other coworkers development in your project, and not having to release your experimental code until it is ready (or even at all.)

So, as long as you stay away from the Push command, you're safe.

Of course, this also assumes nobody is pulling directly from your clone of the repository, if they do that, then of course they will get your experimental changes, but it doesn't sound like you've set it up this way (and it is highly unlikely as well.)

As for the configuration files, the typical way to do this is that you only commit a master file template into the repository, with a different name (ie. an extra extension .template or similar), and then place the name of the real configuration file into the ignore filter.

Each developer then has to make his or her own copy of the template, rename it, and change it in any way they want, without the risk of committing database connection strings, passwords, or local paths, to the repository.

If necessary, provide a script that will help the developer make the real configuration file if it is long and complex.