How to keep uncommitted changes in a local mercurial repository, while still pushing/pulling?

If i'm working on some files that I don't want to commit, I just save them. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down, it asks me to merge or rebase.. but either of these options will cause me to lose my local changes that I have not committed开发者_开发百科.

What are other people doing to get around this? I find the documentation for the shelving extension hard to get my head around.

Note: I'm using Mercurial Eclipse to push and pull files to/from the server.

Any explanation of this would be greatly appreciated! Thanks!

Example:

I'm working on my website in Mercurial Eclipse. I have a new folder and new files that I don't want to commit to the server just yet. I've also modified some existing files and I don't want to make those changes live just yet.

Then something on my website breaks and I need to fix it, it won't let me fix it without rebasing or merging with the most recent tip of the repo and this will cause me to lose all my uncommitted changes.

What should I do with my new folder and files i've edited if I don't want to lose it? Re-cloning seems tedious. Copying the files to a new folder seems tedious as well. I'm sure Shelving or MQ will do what I want, I just don't know how to go about it yet.

With reference to your example situation, here's what I would do (following Ry4an's strategy to just commit the things you're currently working on, but don't want to publish already):

Supposed you start working in a repository like this one:

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

That is there are 2 files and 2 commits/changesets. You do some work, let's say add a new feature, and then your working copy might look like this:

$ hg status
M f2
? f3
? f4

There are 2 new and 1 modified file. Now you have to fix a bug for which you also need any new changes in a remote repository. Snapshot your current work by committing it and pull the remote changes (in which order you do that does not matter, a pull by default does not touch the state of your working copy):

$ hg commit -A -m "snapshot feature work"
$ hg pull

This may result in a history like this:

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Now you can update-to/checkout revision 3 and start fixing bugs:

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

Looks good, let's push your fix, i.e. make it live, while don't publishing your intermediate work:

$ hg push -r 4

This pushes all changes leading to revision 4, your bugfix, but no other branches in your local repository. You could also use -r ., which refers to the parent revision of your working copy, i.e. the revision you just committed.

Finally you can go back to your feature work and continue your work:

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

These steps are on the command line, but I think it's not to hard to adapt the general concept to corresponding clicks in the Eclipse Mercurial plugin.

Some extra notes:

• You may want to bookmark your snapshot commit, so you don't need to work with revision IDs or numbers.
• If you want to publish your feature work in a single commit later, use the collapse extension once you're done.

I'm sure someone will help you find a bad workaround, but the best route is to change you goals -- just commit. Code that hasn't been committed hasn't been written. If you positively can't abide having frequent commits in your history use Mercurial Queues with a queue repository and commit that. You can then pop the changesets, push/pull/merge, and the push them back on, and all you valuable work will be committed in the patch queue.