Navigation

A Better Mirror

Monday, October 15th, 2007

So this afternoon I found out that because of the way I set cvs-trunk-base up, you’ll have to merge every time you do a pull from cvs-trunk-mirror.

This is fairly annoying and generates useless merge commits that probably aren’t the same merges that other people have done, which means you have to do another merge when sharing data between clones of cvs-trunk-base. I think what I was trying to get Mercurial to do was something along the lines of overlay repositories, but support for that sort of thing isn’t quite there yet.

So I did some thinking, and came up with a new plan. I’m going to do two things differently:

  • I’m going to have NSS and NSPR checked directly into the hg repository. There’s really no reason to have them downloading separately for the purposes of this mirror, which is to facilitate Mozilla 1.9 work.
  • Instead of having you pull from cvs-trunk-mirror, I’ll run jst’s hg-track-cvs on this new repository. It seems like a much better solution that trying to trick hg into reparenting revisions.

Hopefully this should create a much nicer place to clone from to do Mozilla 1.9 work with Mercurial.

Oh, and apologies for the repostings that happened earlier today — I upgraded to WordPress 2.3 and converted a bunch of categories into tags. This seems to have caused a number of old articles to appear in my feed again.

Comments

  1. Benjamin Smedberg replied on October 16th, 2007:

    One key advantage of cloning-merging from cvs-trunk-mirror is that changesets can be merged or transplanted fairly easily to mozilla-central… if you do a separate import, it will be an unrelated repository.

  2. Colin replied on October 16th, 2007:

    I don’t think at this point that’s really all that important.

    I don’t think the general developing public is ever going to forward merge to Moz2. When we get enough people doing Moz2 stuff that that would become an issue, we’ll be wanting to focus on Moz2 anyway, so we’ll be backporting. Otherwise, Moz2 folks will be wanting to pull in changes from CVS anyway.

    It sucks if you’re doing something that affects Moz2 **and** 1.9 **and** you want to share changesets between two local repositories, but I think the codebases and workflows are different enough already that there are other problems there. I think a more typical workflow would be to hack on Moz2, and then backport locally to 1.9.

    Overlay repositories are pretty much exactly what we want here, I think. Check out the Mercurial wiki page I linked in the article, you can try it out now.

    I agree though, that long term we want a better solution. Perhaps checking in a version of client.py, or let client.mk know how to deal with hg?