<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Tue, Oct 9, 2018 at 5:49 PM Magnus Melin <<a href="mailto:mkmelin%2Bmozilla@iki.fi">mkmelin+mozilla@iki.fi</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'd like feedback on the below plan for having Thunderbird in a single <br>
repository.<br>
Let's have follow-ups go to dev-planning<br>
<br>
TL;DR version: planning to have current comm-central live as a branch <br>
instead of a separate repository.<br>
<br>
---<br>
<br>
Background<br>
----------------<br>
<br>
When the Mozilla move from CVS to hg took place in 2008, the code <br>
related to Thunderbird was not included in mozilla-central and instead <br>
placed in the comm-central repository. Under the hood Thunderbird uses <br>
the mozilla-central code, so to build it currently has to check out both <br>
repositories. This is not ideal, for many many reasons.<br>
<br>
I wrote [an email to <br>
maildev](<a href="http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2017-November/000875.html" rel="noreferrer" target="_blank">http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2017-November/000875.html</a>) <br>
last year listing some of the drawbacks of this setup - but essentially <br>
what it comes down to is that version control was not meant to be used <br>
like this and it makes workflows error prone, in addition to having to <br>
do various hacks in the build automation. Enabling autoland, phabricator <br>
and other tools used by Mozilla core could also be done much more easily <br>
for comm-central with a single repository.<br>
<br>
The mail spurred some related discussion on git vs hg and importing of <br>
history, but basically there was agreement among the comm-central <br>
developers to go ahead with this change.<br>
<br>
Thunderbird has now migrated its build automation to Taskcluster, and <br>
also moved to building with mozilla-central as topdir, with a comm/ <br>
sub-folder containing comm-central code. (We used to instead have a <br>
mozilla subdir checkout of mozilla-central as child the comm-central <br>
checkout.)<br>
<br>
In 2014 there was [a proposal to merge comm-central code into <br>
mozilla-central](<a href="https://groups.google.com/forum/#!msg/mozilla.dev.planning/P8oHKTCWSiQ/76ECituhK-IJ" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!msg/mozilla.dev.planning/P8oHKTCWSiQ/76ECituhK-IJ</a>) <br>
but this was rejected since the powers that be did not want 1) the <br>
confusion about what code belongs to what project, 2) pull/tree size, <br>
and 3) it was seen as irrelevant to Firefox. The proposal below has none <br>
of these obstacles, and depending on the physical repository location, <br>
may not change anything at all for a Firefox developer.<br>
<br>
I think it's now time to revisit the single repository idea and pull <br>
that through in one way or the other. So, on to the proposal. For <br>
reference, on disk comm/ is on currently 122 MB (+ comm/.hg 192 MB), so <br>
size-wise it is comparatively small, with a mozilla-central checkout <br>
weighing in at 2.3 GB. Including the relevant CVS history, the comm/.hg <br>
would be 317 MB in total.<br>
<br>
How<br>
------<br>
<br>
To capture the essence of what Thunderbird is, we would make <br>
comm-central a named branch of the mozilla-central. Let's call this <br>
branch "comm/default".<br>
<br>
Initially, we'd pull in a hg converted version of the current <br>
comm-central default branch, putting all the files into a comm <br>
sub-folder in the base directory of the comm/default branch. This is the <br>
way that the Thunderbird build system already wants the code laid out. <br>
With the comm sub-folder it will be clear to everyone involved which <br>
code is on mozilla-central code and which is not. It is possible to <br>
import the CVS history for the related directories too while we're at <br>
it, but it adds some size. Importing related CVS history only adds <br>
around 125 MB extra so I'm inclined to include it. With the new <br>
comm/default branch pulled in, we merge the curent mozilla-central <br>
default branch to comm/default. The resulting code is now the same as <br>
status quo (of the both repos pulled in), just that it's all version <br>
controlled in the same repository.<br>
<br>
Once this is all set up, Thunderbird development work would move on on <br>
the comm/default branch, and there would be periodical merges with the <br>
(mozilla-central) default branch. These merges could be automated if wanted.<br>
<br>
Quite often it's the case that Thunderbird code needs to be adjusted to <br>
build, due to changes in mozilla-central code. For cases of known <br>
incoming bustage Thunderbird now would have the possibility of waiting <br>
to do the merge until a fix is available. I would suggest never to back <br>
out bustage causing mozilla-central changesets from the comm/default <br>
branch, but to detect other incoming bustage by doing builds from a <br>
comm/band-aid branch (branced from comm/default). The details on this <br>
can be discussed later though, not to derail discussion about the main <br>
issue here. There are many alternatives, and it's also completely <br>
possible to do what we currently do.<br>
<br>
Where<br>
---------<br>
<br>
In the earlier discussions i's become clear there is a bunch of <br>
confusion around what is a branch and what is a repository, so please <br>
note the difference. Aa repository is the physical location where the <br>
history of a project is stored. Every repository does not have to carry <br>
every branch. I.e., the mozilla-central repository could carry the <br>
comm/default branch, or the comm/default branch could exist only in a <br>
comm-central2 repository somewhere else. In all cases it's trivial for <br>
developers who have mozilla-central checked out, to add the comm/default <br>
branch to their local checkout.<br>
<br>
So for the location there are at least three options:<br>
<br>
A: branch in the mozilla-central repository<br>
B: branch in the mozilla-unified repository<br>
C: branch in a repository elsewhere<br>
<br>
Not to disrupt operations too much I think it would be preferable to use <br>
option B - create the branch in the mozilla-unified repository. It does <br>
depend a bit on what plans Mozilla has for these repositories.<br>
<br>
Creating the branch in mozilla-unified of course needs buy-in from the <br>
Mozilla hg people, so please let me hear your opinions.<br></blockquote><div><br></div><div>So we're all on the same page with regards to terminology and how things work...<br></div><div><br></div><div>"branch" is overloaded to mean different things.</div><div><br></div><div>From a Mercurial VCS perpsective, a "branch" is a name attached to changesets within a repository. Mercurial branches are permanent and pretty heavyweight. They are typically useful for tracking long-lived lines of work, such as releases.</div><div><br></div><div>A Mercurial "branch" is different from a Git "branch." (We won't talk about Git branches here because I don't think it is relevant.)</div><div><br></div><div>>From a Firefox/Thunderbird Mercurial repository perspective, "branch" also means "a specific Firefox repository." e.g. we refer to <a href="http://hg.mozilla.org/{mozilla-central">hg.mozilla.org/{mozilla-central</a>, integration/mozilla-inbound, projects/larch, releases/mozilla-release} as "branches." I find this terminology confusing because "branch" is ambiguous. But it's what a lot of us use. (I would prefer the name "repository" or even "fork" instead.)<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">The Firefox Mercurial repositories typically have a single Mercurial "branch:" "default." Exceptions are the release repositories, which have various branches named *_RELBRANCH.</div><div class="gmail_quote"><br></div><div class="gmail_quote">For historical reasons, the different Firefox Mercurial repositories mostly all have a single DAG head. And that head is on the "default" Mercurial branch.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The mozilla-unified repository is a read-only aggregation of various Firefox repositories. Because the source repositories all use the "default" branch, putting all these changesets in one repository means it isn't clear which changesets "belong" to which repositories because all changesets exist on the "default" branch. The aggregation process invents "bookmarks" so names are associated with each DAG head and you can easily get a pointer to the latest changeset from each source repository.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">There are various things we don't like about the current Firefox repository management. <a href="https://docs.google.com/document/d/1mddoxa2i9ZgPLL_lGOZD0yNyS_ck3v1mzvp4GTEhC-0/edit?usp=sharing">https://docs.google.com/document/d/1mddoxa2i9ZgPLL_lGOZD0yNyS_ck3v1mzvp4GTEhC-0/edit?usp=sharing</a> tracks changes we'd like to make. There is general buy-in to make those changes. But when we last talked about it seriously (at 1 of the prior 2 all hands), we agreed it wasn't high priority. So the work is on hold.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regarding this proposal, I'm going to rule out adding Thunderbird code to mozilla-central (A) at this point in time. People (and automated tools) expect mozilla-central to have a single DAG head / branch and I think adding a 2nd head/branch will cause problems. Plus there's a practical concern of not wanting Thunderbird's code bloating the size of the repository.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Because Thunderbird has separate project governance and support requirements from Firefox (AFAIK), I think we should also rule out adding Thunderbird code to mozilla-unified (B). I'm not super opposed to adding Thunderbird code into mozilla-unified eventually if it makes sense. But I don't think we should do it initially.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I think this new Thunderbird repository should live on its own, independent from the Firefox repositories. Whether changesets should be in the "default" branch or in some other Mercurial branch (so when changesets are pulled into a Firefox repository you know they belong to Thunderbird), I don't have a strong opinion. Having them named differently is more compatible with a world where you are pulling Firefox and Thunderbird repositories into the same repo. But having different branches/names also introduces additional workflow requirements (people need to know to switch between branches - and since we don't use Mercurial branches heavily in Firefox land, people may not know how to do that).<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
What about history?<br>
--------------------------<br>
<br>
For the proposed approach (going through `hg convert`) commits are <br>
preserved, but AFAIK it's not possible to preserve actual commit hashes. <br>
`hg convert` will graft the original commits, and this adds the original <br>
hash as an extra field to the new commit (use `hg log --debug` to see <br>
it). I don't think this is such a big problem. The original commits <br>
would be linked in the pushlog, the same way there is "converted from" <br>
for mozilla-central-cvs, like <br>
<a href="https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/ab117d946959" rel="noreferrer" target="_blank">https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/ab117d946959</a>. <br>
I don't see them e.g. in <br>
<a href="https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central/rev/8f8b0933b611" rel="noreferrer" target="_blank">https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central/rev/8f8b0933b611</a> <br>
so perhaps there is some server side feature that needs turning on?<br></blockquote><div><br></div><div>Correct. We have a very minimal server extension to render the "convert_revision" changeset metadata (run `hg log --debug` to see it) as a link to another repository. Since the conversion only stores the hash of the source revision, we need to add a config option to the .hg/hgrc of the repository to define which source repository to point to.</div><div><br></div><div>It appears modern versions of Mercurial support recording "convert_source" changeset metadata (<a href="https://www.mercurial-scm.org/repo/hg/rev/c9093d4d1ff6">https://www.mercurial-scm.org/repo/hg/rev/c9093d4d1ff6</a>). We should change our server extension to always render that, if available. Please file a Developer Services :: <a href="http://hg.mozilla.org">hg.mozilla.org</a> bug to request that feature if you will use it.</div><div><br></div><div>Anyway, I added the server config setting so the "converted from" links now render on your user repository.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Can I try it?<br>
---------------<br>
<br>
You can check <br>
<a href="https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central/" rel="noreferrer" target="_blank">https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central/</a> which <br>
carries the comm/default branch.<br>
<br>
In your mozilla tree, pull in the branch like this:<br>
<br>
      hg pull -u -b comm/default <br>
<a href="https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central" rel="noreferrer" target="_blank">https://hg.mozilla.org/users/mkmelin_iki.fi/thunderbird-central</a><br>
<br>
To completely remove it again, use `hg strip "branch(comm/default)`<br>
<br>
How did you do it?<br>
------------------------<br>
<br>
     CVS_GIT_REPO=~/tmp/mozilla-cvs-history/<br>
     CC_HG_REPO=~/Code/tb/mozilla/comm/<br>
<br>
     git clone <a href="https://github.com/ehsan/mozilla-cvs-history.git" rel="noreferrer" target="_blank">https://github.com/ehsan/mozilla-cvs-history.git</a> <br>
$CVS_GIT_REPO<br>
<br>
     echo default comm/default | tee branchmap.txt<br>
     echo rename . comm | tee filemap.txt cc0.txt<br>
<br>
     hg --cwd=$CC_HG_REPO up 0<br>
     (cd $CC_HG_REPO && ls -d */ | cut -f1 -d'/' | sed 's/^/include /') <br>
 >> cc0.txt<br>
<br>
     hg convert --filemap=cc0.txt --branchmap=branchmap.txt <br>
$CVS_GIT_REPO single-repo/<br>
<br>
     CVS_TIP=`hg id --cwd=single-repo -i -r tip --debug`<br>
     CC_0=`hg id --cwd=$CC_HG_REPO -i -r 0 --debug`<br>
     echo $CC_0 $CVS_TIP | tee splicemap.txt<br>
     # e4f4569d451a5e0d12a6aa33ebd916f979dd8faa <br>
93dd94bad983ce2eff5f228719c349b78a8a7f7d<br>
<br>
     hg convert --config convert.hg.saverev=True <br>
--splicemap=splicemap.txt --filemap=filemap.txt <br>
--branchmap=branchmap.txt $CC_HG_REPO single-repo/<br></blockquote><div><br></div><div>You may also want to add the config options from <a href="https://hg.mozilla.org/hgcustom/version-control-tools/file/d54b06ec9d16/vcssync/mozvcssync/git2hg.py#l71">https://hg.mozilla.org/hgcustom/version-control-tools/file/d54b06ec9d16/vcssync/mozvcssync/git2hg.py#l71</a> to ensure file copies and renames are more robustly detected. The conversion will take longer. But it's a one-time thing and accuracy is probably worth burning a few trillion CPU cycles on :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For fun, see all the history down to 1999 is there, like<br>
<br>
     hg log comm/mailnews/mime/src/mimei.cpp<br>
<br>
Then go on and add the default branch from mozilla-central and do the merge<br>
<br>
     cd single-repo<br>
     hg pull -f -b default $CC_HG_REPO/..<br>
<br>
     hg up comm/default<br>
     hg merge default && hg commit -m "Merge default to comm/default branch"<br>
<br>
     hg push -f -b comm/default --new-branch thunderbird-central-push<br>
<br>
---<br></blockquote><div><br></div><div>As for converting CVS history, I'm +1 on that.<br></div><div><br></div><div>I wouldn't plan on the hashes aligning between any future "official" conversion of the Firefox CVS history to Mercurial and what you did or what any other conversion did. *If* we produce an official Mercurial repository with CVS history, we will likely do so using a different technique than what existing conversions have done with conventional tools. (If we do an official conversion or any other kind of flag day conversion, we'll likely switch to Mercurial's "tree manifests" feature and that will rewrite hashes by definition. And we will also likely wait for a non-SHA-1 hash to be supported by Mercurial.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thoughts, comments, feedback appreciated!<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Overall this all seems pretty reasonable! Speaking as an hg.mo service operator and someone with domain expertise about converting repositories, I would like to perform a final review on everything before this goes into production though. Please flag me for needinfo on a bug or reach out privately. I'm on PTO a bit in the next ~2 weeks though. Please reach out to my manager - Kim Moir - if I'm not responsive. And feel free to drop into #vcs to ask questions.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thank you for taking the time to write all this up and for reaching out for feedback.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
  -Magnus<br>
<br>
_______________________________________________<br>
dev-planning mailing list<br>
<a href="mailto:dev-planning@lists.mozilla.org" target="_blank">dev-planning@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-planning" rel="noreferrer" target="_blank">https://lists.mozilla.org/listinfo/dev-planning</a><br>
</blockquote></div></div></div></div></div></div>