comm-central defaults changed to follow mozilla-1.9.1 branch
Mark Banner
http://ccgi.standard8.plus.com/blog/archives/64]
[Follow-ups to mozilla.dev.planning]
Now that mozilla-central has created a mozilla-1.9.1 release branch,
we’re updating the comm-central build system to build mozilla-1.9.1 by
default.
Here’s a little Q and A that I hope should answer most questions.
Q. Why are we doing this?
A. The next versions of Thunderbird and SeaMonkey will be shipped from
Gecko 1.9.1 (which Firefox 3.1 will be shipped from), we need to modify
our build system to move everyone onto the Gecko 1.9.1 branch
(mozilla-1.9.1).
Q. Why is comm-central not branching?
A. The work and time remaining for Thunderbird 3, SeaMonkey 2 and
Sunbird/Lightning is significant enough that we consider branching at
this stage to be too early. We will be branching closer to the release.
This will save some management of two individual branches.
Q. What happens to current build my repositories?
A. We will be updating client.py. Once you pick up that update, the next
time you run client.py it will:
* Move your existing mozilla/ directory to .mozilla-trunk
* It will clone a new mozilla/ directory from .mozilla-trunk (so
that you don’t need to download all of the mozilla-1.9.1 repository)
* It will then make your new mozilla/ directory pull from the
mozilla-1.9.1 release branch.
Q. What happens to building with mozilla-central trunk?
A. At the moment maintaining comm-central with mozilla-central trunk
builds is very low priority. To start with, there will be no
comm-central with mozilla-central tinderbox coverage.
We’d like to keep up with current developments so that we don’t stray
too far, however the priority is for us to ship the next versions of
Thunderbird/SeaMonkey from the mozilla-1.9.1 branch.
We’ll be posting more on how we’re going to manage mozilla-central trunk
builds soon.
Q. I want to stick with mozilla-central trunk, how do I do this?
A. If you’re pulling a new mozilla/ tree then you can do:
python client.py checkout
–mozilla-repo=http://hg.mozilla.org/mozilla-central/
Otherwise, you can manually pull mozilla-central or mozilla-1.9.1 into
the mozilla/ directory.
We’ll be adding additional command-line options later.
Q. What happens to locally-cloned mozilla-central repositories?
A. These will still pull from their original locations. You’ll probably
want to update their current pull locations and/or check they are
pulling the correct code.
Mark Banner
Following on from the changes, mentioned before, we'll be keeping the
comm-central tree closed overnight to let tinderbox settle down and
ensure we get new nightlies correctly.
We are therefore limiting all changes to comm-central to only those
required for TB or SM releases, or which have specific approval.
We'll re-open the tree as soon as is reasonably possible.
Standard8
timeless
you need to do:
cd .mozilla-trunk; hg up -r null
in order to satisfy mxr.
the reason mxr ident doesn't find files in .hg/.svn is because their
extensions aren't interesting, not because the file is in a directory
named .foo. mxr search explicitly ignores files in directories with
very specific names (.hg, .git, .svn, .bzr, CVS, perhaps a limited
number of others), which means the directory itself will still be
found if someone searches for 'mozilla', however as long as it's
empty, that won't hurt much.
Justin Wood (Callek)
Ahhh, I wished I realized that :/
I haven't checked yet, but has this been fixed locally for mxr yet?
and/or a bug filed?
--
~Justin Wood (Callek)
timeless
> Ahhh, I wished I realized that :/
>
> I haven't checked yet, but has this been fixed locally for mxr yet? and/or a
> bug filed?
i don't really see a bug on my part.
you can use hg up -r null in .mozilla-trunk, that'll neutralize it.
Robert Kaiser
But we explicitely don't kill the old mozilla tree because that's bad
for developers who want to test with it or who do have changes in it.
Robert Kaiser
timeless
> But we explicitely don't kill the old mozilla tree because that's bad for
> developers who want to test with it or who do have changes in it.
quite unfortunate. you can try moving it to be a sibling of
comm-central. with a note that people can move it back as long as they
leave a file/directory in its place.
Robert Kaiser
The right solution is to rm -rf the .mozilla-trunk directory on all
trees that don't need to care about keeping it - just like I did on our
buildbot slaves. The same should IMHO be done on MXR.
Robert Kaiser
Philip Chee
Actually I quite like the current situation as I can query 1.9.1 and
1.9.trunk at the same time instead of opening two tabs and then
switching back and forth.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I'm not a witch doctor-- I'm only a folk medic.
* TagZilla 0.066.6
Justin Wood (Callek)
> On Tue, 02 Dec 2008 23:28:40 +0100, timeless wrote:
>> On Wed, Dec 3, 2008 at 3:47 PM, Robert Kaiser <ka...@kairo.at> wrote:
>>> But we explicitely don't kill the old mozilla tree because that's bad for
>>> developers who want to test with it or who do have changes in it.
>> quite unfortunate. you can try moving it to be a sibling of
>> comm-central. with a note that people can move it back as long as they
>> leave a file/directory in its place.
>
> Actually I quite like the current situation as I can query 1.9.1 and
> 1.9.trunk at the same time instead of opening two tabs and then
> switching back and forth.
>
Imo (and agreed by some other devs) is that the bloat in mxr for this is
not worth it atm.
I should note that I also explicitly named the folder |.*| in the hopes
that mxr would ignore it and it would not cause confusion for local devs.
--
~Justin Wood (Callek)
timeless
> I should note that I also explicitly named the folder |.*| in the hopes that
> mxr would ignore it and it would not cause confusion for local devs.
i take a fairly conservative approach to hiding things.
http://mxr-test.konigsberg.mozilla.org/mozilla-central/find?string=/\.
of interest to me beyond the cvsignores, hgignores and hgtags file is
the .typeAttributes.dict file
along with the fact that there's actually a second hg repo on
konigsberg in this tree (tamarin) which can be identified by the
presence of its .hgignore file.
perhaps more interesting is:
http://mxr-test.konigsberg.mozilla.org/mozilla-org/find?string=/\.
which has a number of .htaccess files which are important and
shouldn't be ignored.
the .DS_Store files are questionable, but perhaps someone would want
to know they exist so they could choose to kill them.
mozdev has random files of interest including this one:
http://mxr-test.konigsberg.mozilla.org/mozdev/source/foxgame/src/foxgame-14X/.classpath
and this file which probably shouldn't have been checked in:
http://mxr-test.konigsberg.mozilla.org/mozdev/source/ghostfox/www/.%23html_body.html.1.2
yes, /source/ won't show these files, but they're still worth supporting.
I could search other trees, but I hope you'll agree that a blanket
hiding isn't ideal.
It's probably possible to write a filter if you really care.
http://mxr-test.konigsberg.mozilla.org/comm-central/find?string=^%28%2F[^\.][^%2F]*%29*%24
http://mxr-test.konigsberg.mozilla.org/comm-central/ident?i=PRLogModuleInfo&filter=^%28[^%2F]*%2F[^\.][^%2F]*%29*%24
seems to avoid hidden files
Justin Wood (Callek)
> On Thu, Dec 4, 2008 at 2:04 AM, Justin Wood (Callek) <Cal...@gmail.com>
> wrote:
> > I should note that I also explicitly named the folder |.*| in the hopes
> that
> > mxr would ignore it and it would not cause confusion for local devs.
>
> i take a fairly conservative approach to hiding things.
Which I see now ...
> I could search other trees, but I hope you'll agree that a blanket
> hiding isn't ideal.
>
I actually could see the "use" for this from the moment you told me it
wasn't that way; I just (mistakenly) assumed it was
> It's probably possible to write a filter if you really care.
>
Probably best to simply remove the "bad" dir. (either via |rm -rf| or via
|hg up -r Null|)
--
~Justin Wood (Callek)