Struggling with Mercurial
By Weijun-Oracle on Dec 19, 2007
But at the same time, I still have to get my work done, fixing bugs and implementing RFEs. The teamware workspaces are gone, and I've fcloned the whole forest on my own computer. What shall I do if I cannot name the changesets and push them back? So I'm trying the Mercurial Queue extension now.
The tool is great by letting you doing groups of code changes one after one, in a special kind of changeset called patch. They're real changesets, except that it's very easy to apply or de-apply them as a series. Therefore, it's an ideal tool for me now to work on bugs/RFEs one after one, and I know I can change the comment names later.
I've found several problems (and solutions) so far:
- You have to to work on them one after one, which means you cannot work on several bugs simultaneously. Without the extension, in the simpler case, if several bugs need changes in different files, you can just do them both. When any one is done, run "hg commit filenames" on its affected files and the changes go into its own changesets, and then the other, the other. With the extension, I don't know if I can control "qnew" and "qrefresh" to act on a sub area of the whole repository. Seems not, so I have to create multiple patches, and "qgoto" the one each time I want to work on another fix (and remember to qrefresh before switching to another one), even though they are touching completely different files.
- There's an order of which patch comes after which. This order is determined when each "qnew" is called, and finally they should be pushed back in this order. What if I need to change the order? What if I just have to drop one? My current solution is to manually edit the "series" file after calling "hg qpop -a", and them qpush in the new order (Thanks to the clean and whitebox designation of MQ. You're so kind!). Sometimes, if 2 patches make changes to the files, I use the "flippatch" tool to update the patches themselves. Of course, manual check is always a must after the flip, to make sure the history is not corrupted.
- I don't know if there's a standard way to change the patches into formal changesets when I'm sure the upstream repository already accepts my push backs. I can manually edit the "series" file again and remove the patches. This is not a serious problem. Update(2008-01-04): Just write a script to automatically change the topmost patch into a normal commit. I just qdelete the patch from series, patch it explicitly (by running the patch command), and then commit it. I've made sure to take care of the added and removed files.