IRIX and Software

Hey guys, I'm trying to compile the Dillo browser, with an eye toward adding it to nekoware, using the MIPSPro compiler this time since there appear to be intractable problems with gcc, but after I made a ton of changes to three files in their most recent release (version 3.0.2), the authors told me to give up on that and start over using the tip of their mercurial repository. Admittedly, I had been bugging them a lot on their mailing list. So anyway, I want to merge my changes into the pull I made of their mercurial repository, but I'm a total mercurial newb. I mean, I think what I'm trying to do is really simple, but I just spent hours digging through the mercurial docs and so far I've got nuthin! So my question is, if I've got their latest and greatest in directory dillo3, and my changes to the 3.0.2 source are in directory dillo-3.0.2-irix-changes, how do I merge those changes back? What I tried, but that didn't work for reasons I don't pretend to understand:

From the dillo3 directory (note: all the changes that I made are "commited" in the dillo-3.0.2-irix-changes directory):

vishnu@starhunter:~/dillo3$ hg pull ../dillo-3.0.2-irix-changes/
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 3 files
(run 'hg update' to get a working copy)


At this point I found that doing `hg update` doesn't merge the changes I made, it blows away the files with all the changes the authors have made since the 3.0.2 release and replaces them with the files I changed from the 3.0.2 release. So I undo that and instead try to merge:

vishnu@starhunter:~/dillo3$ hg merge
abort: there is nothing to merge - use "hg update" instead


What the hell? Did it not just tell me at the pull that it sees three changesets with changes to three files? And mercurial is supposed to be an improvement over CVS?

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.

I didn't make any patch files, I just edited three of the files from the Dillo 3.0.2 release and hoped mercurial could merge those into a pull I made from the tip of the Dillo repository. I just wasn't sure how to tell mercurial to do that...

Does the dillo release source actually have a .hg directory in them? In my experience it's common practice to leave version history out of relesed sources which means you don't have one part of the two histories to merge.

Indeed the dillo source tarball that I'd been working from didn't have an .hg directory, so I pulled the 3.0.2 source from the dillo mercurial repository to get one...

Hmm, well that's what you get for replying when half-asleep; I misread your post pretty bad it seems. Sorry.

My advice is, start with a fresh clone of the upstream, make your changes again to the current rev, and then hg commit. When you're ready for an update, hg pull and hg rebase as above. Conflicts it can automatically resolve it will; conflicts it cannot you must (and then hg resolve -m and hg rebase --continue).

I agree that hg merge is a total misnomer; it rarely does what people expect it should do.

Thanks Classic that worked!

You'd think that would be in the faq somewhere...

It's not at all obvious what has to be done. I had to figure this out myself. You wouldn't believe the number of times I ended up pulling mozilla-central until I got the steps right ...

And I'm sure subversion and git are just as bad, if not worse. Kidding! I only kid. No seriously...