1683397 - Identify files that conflict between m-c and c-c and find workarounds

Status: NEW

(Thunderbird :: Build Config, task)

Description

[Rob Lemley [:rjl]]

There are some files that are in the root of both mozilla-central and comm-central that due to their nature will need to be in the root of comm-single and differ from mozilla-central. The goal is of course to not change files outside of comm/, but there will be exceptions.

Files I have identified so far:

.arcconfig
.cron.yml
.hg-annotate-ignore-revs
.hgignore
.hgtags
.taskcluster.yml

Some of these have easy-ish solutions -

.hgignore - I think we can safely remove comm/.hgignore as everything in it looks like it is covered by the one from m-c. The m-c one needs to have the comm/ line removed.

.taskcluster.yml, .cron.yml, .arcconfig - These must live in the repo root and will be different in comm/default branch. It looks like overwrites can be avoided by using merge-patterns. I have an hgrc with:

[merge-patterns]
.arcconfig = :merge-local
.cron.yml = :merge-local
.taskcluster.yml = :merge-local

When merging from m-c:default to c-c2:comm/default that should take the version in c-c2 over the one from m-c. The problem with that approach is that incoming changes will not be easily detected and could cause bustage. We may want to write a custom merge-tool to handle files like this that warns about incoming changes so they can be handled by a developer.

Side note - .cron.yml in particular needs to be looked at. ci-admin reads this to run the dailies and it probably only looks at the "default" branch.

Other less easy ones:
.hgtags - This needs to be in the root. I think we can have it differ on comm/default like above. The docs appear to say that different branches can have different tag files. That implies that comm/default's .hgtags would only contain Thunderbird related tags.

.hg-annotate-ignore-revs:
This will be really fun since the hashes all changed in the new repository and it's not autoupdated by hg convert. I don't know much more about this file and how branches might come into play.

Comment 1

[Magnus Melin [:mkmelin]]

For .hgtags, there are some weird ones in there, we need to use more sensible names than BETA_BASE_20201214 (something with THUNDERBIRD_?). Probably makes sense to merge the c-c ones in, and just handle conflicts as they come. Maybe hg is smart about it?

.hg-annotate-ignore-revs: same here. hg converts adds the annotation of what the original commit was, we should be able to figure them out and add