What exactly is in your changes directory? Patches, or actual files?
If they are patches, you should hg import them, with --no-commit if you don't actually want a commit for each patch.
If they are files, copy the files to their destination, overwriting them if necessary. Now do an hg status. You should see a list of the modified files, something like
M foo/bar.c
M foo/baz.c
M woz/wuz.h
If you see
? my/new/hotness.cpp
this means a file Mercurial doesn't know about, and it will ignore. If this is a new file, you need to hg add my/new/hotness.cpp, and then it will change to "A" (meaning it will be added to the repo).
At this point you can do an hg diff for a naked diff without committing, or hg commit the changes and later hg export that specific rev (hg export -r 98765) if you want the diff in the future. You can take that and use it as a changeset for hg import (see below).
If you want your changes to float to the top, here's how to do that (I track the Mozilla rapid-release repos and have the TenFourFox changesets layer on top):
- hg export all your current local changesets somewhere.
- Make a new clone repo with hg clone
http://url/of/the/repo
, and specify the desired rev if you want. All pulls will now come from the master repo, which is what you want usually.
- hg import your changeset(s) in numerical order by rev. If you get conflicts at this point, merge them, then hg commit, then continue with the next changeset until all are imported. You are now current.
- When you want to pull new changes, hg pull, and then hg rebase (NEVER hg merge in this circumstance). You will undoubtedly get some merge conflicts, each of which you manually resolve in $EDITOR, and then hg resolve -m to commit the resolved merge. When ready to continue the rebase after a conflict is resolved, hg rebase --continue.