You can learn more about advanced MQ usage from the reference page, but you should now know enough to be able to use MQ effectively for Mozilla development work. Your patches that conflicted should now apply cleanly until the next time you update and a conflict occurs. rej files that are listed), and hg qrefresh the patch to save your changes. If you haven't setup a merge tool, you'll need to open the files that had conflicts, fix up the bits of your patch that were in conflict (look at the. It turns out that the recent changes to mozilla-central have modified the same files as your bug-123456-fix patch. Patching file extensions/cookie/test/test_loadflags.htmlġ out of 1 hunks FAILED - saving rejects to file extensions/cookie/test/test_Įrrors during apply, please fix and refresh patch Instead, you should pop them all before updating, like so: $ hg qpop -a It is very dangerous to pull remote changes while you have MQ patches applied (unless you are using the rebase extension). The last important step is updating your mozilla-central repository. You can now qpush your way back to bug-341896-fix if you want to keep working on it, or qnew yourself an entirely new patch to work on! If you compare bug-123456-fix.patch and bug-123456-v2.patch, you'll see your most recent changes reflected in the second. Using qpush and qpop, you can apply and revert your patches until the one you want to modify is current. MQ makes it easy to go back and fix up earlier work: $ hg qpopġ U bug-341896-fix: Bug 341896: The fix, summarized briefly. Let's say that the your fix for bug 123456 is reviewed, and you need to make a couple changes. This shows all of the patches you have in your queue. hg qseries demonstrates this: $ hg qseries -v -sĠ A bug-123456-fix: Bug 123456: A brief summary of the changes you have made.ġ A bug-341896-fix: Bug 341896: The fix, summarized briefly. MQ allows you to keep your unrelated changes isolated from each other. If you look at the new patch file you have exported, you'll notice that it only contains the changes for your bug-341896-fix mq entry. $ hg export qtip > ~/bug-341896-fix.patch $ hg qrefresh -m "Bug 341896: The fix, summarized briefly." The process is exactly the same: $ hg qnew bug-341896-fix While the patch is being reviewed, you might want to work on another bug. $ hg export qtip > ~/bug-123456-fix.patch $ hg qrefresh -m "Bug 123456: A brief summary of the changes you have made." The following commands demonstrate how to create an MQ entry for a single bug fix, record the changes you make, and turn them into a diff file named "bug-123456-fix.patch" that is ready to be attached to the corresponding Bugzilla bug. Remove an unapplied patch from your queue. Update the current patch to include your latest uncommitted changes. Make a new empty patch and give it a name. This allows changing binary files in your patches. To enable MQ, put this in your Mecurial.ini file for Windows (see mozilla-build in Windows Build Prerequisites) or $HOME/.hgrc file: ĭon't forget the git line. hg/patches directory under the repository. You can apply them as Mercurial changesets, unapply them, edit them, and when they're done, turn them into permanent changesets and push them.Įach repository has its own queue of patches managed by MQ. The MQ extension lets you treat a stack of patches as works-in-progress. The output of a developer (on a good day, anyway) is patches. The mqext extension can make this much easier. Version your patch queue to save changes.Ensure you use the latest stable release of Mercurial. Otherwise you will lose any changes to binary files. It is sharp and can mess up your repository if used incorrectly. If someone pulls one of them, you'll never get rid of it. MQ creates temporary changesets in your repo.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |