Patch management between repositories?

Gecko 1.9 is nearly here, and I’m looking forward to it. But there’s a catch… I have to make some fairly extensive changes to it, changes that will not live in the 1.9 repo on any branch. So I’m hoping a few people can point me to some nice freebie tools for applying patches in one repository to another repo’s code, and keeping the patches up to date. Or for handling cross-repository (and for that matter, cross-repository-platform) patches in general.

(The concept I have is that, following the new XULRunner build system, my app’s source would live in mozilla/verbosio – from a separate repository than the 1.9 code base.)

From my brief research, Mercurial Queues seems perfect for this – within Mercurial repositories anyway. Apparently, the 1.9 CVS stable branch will not be tracked in parallel on after RC1 (grumble, grumble), so I’m not sure how MQ could be used in this scenario. Or I’d have to host the whole Moz code plus my project in hg, and do catch-up merges from CVS as new point releases come up. (If I go that route, I’ll have to be super-nice to the mozdev folks and bribe them to set up and host a clone…)

Believe me, it’s very little fun to try making two repo systems work together. The equivalents of CVS ignore are just the beginning of the pain.

Another question that comes to mind is: how do you make comments inside a GNU diff file? Do they support, like Perl does, a hash-begins-a-comment-line form of commenting, at least between files? That would make it easier for me to document these patches I’d keep.

I’m also hoping someone will take the time to publish a Mercurial guide in hardcopy. I really appreciate William Nagel’s “Subversion Version Control” — it’s much easier to understand than

I can probably write some simple Perl code to apply the patches as I just mentioned, but maintenance is another issue. Please advise.

6 thoughts on “Patch management between repositories?”

  1. My suggestion is to _locally_ use:
    To keep up to date with changes to 1.9.
    Then pull from that local repo into your Hg Tree.
    If you do not want to host all of mozilla on MozDev you can simply use hg outgoing and similar to find out what differs between your mozilla tree and your hg cvs copy.
    You can then write a python script (such as mozilla-centrals to checkout Mozilla from 1.9; apply your specific patches and checkout the verbosio code from whatever type of repository you want to you.
    The HgBook I have been reading online is quite good (a few minor errors I have found, that I have notified the author on) but all in all, everything is great!

  2. You can add comments to your hg patch with mq by doing |hg qrefresh -e| 😉
    With that said, I think a case can be made to maintain the cvs-trunk-mirror (for those who have to backport branch patches at least). jst has the scripts, so it’s likely you just need to find someone to push the changes who has commit rights. This is all a lot of handwaving, but talking with bsmedberg on irc the other day, this didn’t seem too difficult to do.

  3. cvs-trunk-mirror only really matters if it’s important to keep individual checkins as changesets. If it isn’t, then you could just import the 1.9 code into your own Hg repo, and periodically update by just copying in the new code. You could then maintain your own changes in either a separate branch, and merge from 1.9 over to your branch, or use mq and keep it as a patchset, although that seems kind of silly.

  4. This isn’t related to the subject of your post, but rather its format: on planet, it looks like your post ends after the one-sentence parenthetical paragraph, with no indication that there’s more to read on-site. If you don’t want to include a full-content feed, could you please include a “More” notice at the point where the post is otherwise chopped off? Thanks!

Comments are closed.