18
edits
Using Mercurial locally with CVS: Difference between revisions
m
http://developer.mozilla.org/en/docs/Mercurial tag for this file
No edit summary |
m (http://developer.mozilla.org/en/docs/Mercurial tag for this file) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
'''Note: that this is only useful for code that's still exclusively in CVS.''' | |||
<!-- | |||
see http://developer.mozilla.org/en/docs/Mercurial | |||
--> | |||
This page is an introduction on how to use Mercurial locally with CVS. That is, code is still checked out/committed to the Mozilla repository using CVS, but all local work is done using Mercurial. | This page is an introduction on how to use Mercurial locally with CVS. That is, code is still checked out/committed to the Mozilla repository using CVS, but all local work is done using Mercurial. | ||
| Line 45: | Line 50: | ||
.*/CVS/.* | .*/CVS/.* | ||
.*/NONE | .*/NONE | ||
\.\#.*$ | |||
^\.cvsignore$ | |||
^\.DS_Store$ | |||
^Makefile$ | ^Makefile$ | ||
^config.log$ | ^config\.log$ | ||
^config.cache$ | ^config\.cache$ | ||
^config.status$ | ^config\.status$ | ||
^.client-defs.mk$ | ^\.client-defs\.mk$ | ||
^config-defs.h$ | ^config-defs\.h$ | ||
^.mozconfig$ | ^\.mozconfig$ | ||
^.mozconfig.mk$ | ^\.mozconfig\.mk$ | ||
^.mozconfig.out$ | ^\.mozconfig\.out$ | ||
^a.out$ | ^a\.out$ | ||
^unallmakefiles$ | ^unallmakefiles$ | ||
^nss$ | ^nss$ | ||
^mozilla-config.h$ | ^mozilla-config\.h$ | ||
.flc$ | \.flc$ | ||
.orig$ | \.orig$ | ||
.pyc$ | \.pyc$ | ||
<tt>hg addremove</tt> marks any files in the working dir that aren't present in the repository for addition, and marks any missing files as missing. The <tt>hg commit</tt> will create your initial commit. | <tt>hg addremove</tt> marks any files in the working dir that aren't present in the repository for addition, and marks any missing files as missing. The <tt>hg commit</tt> will create your initial commit. | ||
| Line 132: | Line 139: | ||
% hg commit -m "cvs sync" | % hg commit -m "cvs sync" | ||
Then, you need to update your local clone(s): | (Tip from my Sylvain on my blog: you can combine the last two lines into just <tt>hg commit -A -m "cvs sync"</tt>; once in a while I end up with leftover CVS .foo.12.3 files that I don't want committed though, so it's nice to be able to verify before committing.) Then, you need to update your local clone(s): | ||
% cd mozilla | % cd mozilla | ||
| Line 176: | Line 183: | ||
* <tt>hg update tip</tt> to jump to the latest tip that you just pulled from the CVS repo, and then use the transplant extension to move your patch(es) over from previous change sets. e.g. <tt>hg transplant 255</tt> to take changeset 255 and apply it to the current working dir. Transplanting in this way is very similar to <tt>hg export 255 > foo.patch</tt> followed by a <tt>patch -p1 < foo.patch</tt>, <tt>hg commit -m "orig commit message"</tt>, except that it will stop and ask you to fix up conflicts. | * <tt>hg update tip</tt> to jump to the latest tip that you just pulled from the CVS repo, and then use the transplant extension to move your patch(es) over from previous change sets. e.g. <tt>hg transplant 255</tt> to take changeset 255 and apply it to the current working dir. Transplanting in this way is very similar to <tt>hg export 255 > foo.patch</tt> followed by a <tt>patch -p1 < foo.patch</tt>, <tt>hg commit -m "orig commit message"</tt>, except that it will stop and ask you to fix up conflicts. | ||
== Managing patches == | |||
This is a brief introduction to MQ, the Mercurial Queues extension. You must explicitly enable it by adding | |||
hgext.mq = | |||
to the <tt><nowiki>[extensions]</nowiki></tt> section of ~/.hgrc or Mercurial.ini. You'll know whether it's enabled if <tt>hg qapplied</tt> doesn't return an error about an unknown command. | |||
A much more comprehensive overview is available in [http://hgbook.red-bean.com/hgbookch12.html#x16-26500012 the MQ chapter of the hg book]. | |||
=== Creating a new patch === | |||
% cd mozilla | |||
% hg qnew 369012-fix-bad-crash | |||
% <nowiki>[hack hack hack]</nowiki> | |||
% hg qrefresh | |||
The above initializes a new patch named "369012-fix-bad-crash" (you can use any valid filename that you wish, though I tend to prefix things with the bug number... I use xxxxxx if no bug has been filed yet). After you make your changes, <tt>hg qrefresh</tt> updates the topmost patch with the current diff from the working directory. | |||
You can also create a patch after the fact, incorporating any outstanding changes in the working directory into it. This is the way that I tend to work: | |||
% cd mozilla | |||
% <nowiki>[hack hack hack]</nowiki> | |||
% hg qnew -f 369012-fix-bad-crash | |||
The <tt>-f</tt> informs qnew to take the outstanding changes and make them part of the patch; otherwise, qnew will complain about outstanding changes and refuse to make a new patch. | |||
After either of these steps: | |||
% hg qapplied | |||
369012-fix-bad-crash | |||
% hg qtop | |||
369012-fix-bad-crash | |||
<tt>qtop</tt> will show you the current topmost patch, and <tt>qapplied</tt> will show you the list of applied patches. Let's say you make another patch: | |||
% ... make changes ... | |||
% hg qnew -f 301123-new-feature | |||
% hg qapplied | |||
369012-fix-bad-crash | |||
301123-new-feature | |||
% hg qtop | |||
301123-new-feature | |||
The <tt>301123-new-feature</tt> patch is created <i>relative to</i> the previous patch for 369012. This is important in case you ever want to reorder patches, or if you need to submit patches for review that have dependencies on other patches. | |||
You can pop the topmost patch from your working directory: | |||
% hg qpop | |||
Now at: 369012-fix-bad-crash | |||
Note that these patches live as normal patch files in the .hg/patches directory; this is what I use for submitting patches for review. The order in which they're applied is just a text file in .hg/patches/series -- <i>but don't edit the order of currently applied patches, because bad things will happen.</i> | |||
Note that while patches are applied, they show up as real changesets in the repository: | |||
% hg qapplied | |||
one | |||
two | |||
% hg log -l 3 | |||
3[qtip,tip,two] c1e6c90c12ad 2007-07-31 15:20 -0700 vladimir | |||
imported patch two | |||
2[qbase,one] 2ba59c979503 2007-07-31 15:18 -0700 vladimir | |||
[mq]: one | |||
1[qparent] 587167de96c1 2007-07-31 14:42 -0700 vladimir | |||
Add mystery message to README.txt | |||
This is why it's important to <tt>qpop -a</tt> to remove all patches from the stack before doing any pushing or pulling from your working repository. Otherwise, the remote doesn't have any idea of your patches, and these will just show up as changesets. | |||
When you're ready to commit a patch, the easiest thing is: | |||
% hg qpush | |||
Now at: one | |||
% hg qapplied | |||
one | |||
% hg qrm -r one | |||
<tt>qrm -r <i>patchname</i></tt> tells mq to stop managing the patch named <i>patchname</i> which must a) be applied; and b) be the bottommost patch on the stack. At that point, that patch is just a normal changeset, and you can proceed with the "committing to CVS instructions". | |||
Some other useful commands: <tt>hg qdiff</tt> will show you the diff between your working dir and the previous patch; this is different from <tt>hg diff</tt>, which will show you the diff between your working dir <i>and the last time you refreshed the topmost patch</i>. Both are useful. You can rename patches using <tt>hg qrename</tt>, e.g. to give a patch a bug number. You can also give a patch a commit message, either at <tt>qnew</tt> time using -m, or at <tt>qrefresh</tt> time, also using -m. | |||