Meta's Sapling source-code management system

Posted Nov 17, 2022 12:51 UTC (Thu) by nysan (guest, #81015)
In reply to: Meta's Sapling source-code management system by khim
Parent article: Meta's Sapling source-code management system

"The trick is simple: don't provide means to combine two versions. Period."

OK, so you have 40 ppl working on feature X, and 40 ppl working on feature Y.
In the end, you need to integrate and test X and Y together, since they are dependent.
Merging X first, and Y second does compile, but can't be integration-tested.

How would you do this, in case you only allow a single CM version in the monorepo ?

Meta's Sapling source-code management system

Posted Nov 17, 2022 14:07 UTC (Thu) by pkolloch (subscriber, #21709) [Link]

Incremental integration with feature flags.

Meta's Sapling source-code management system

Posted Nov 17, 2022 14:36 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

> Merging X first, and Y second does compile, but can't be integration-tested.

If that's a monorepo then there are no merging. Individual commits are merged, of course (you can not have few thousand people working on the same code and not have some conflicts) but features are never implemented in branches.

Branches are for bugfixes.

Android couldn't follow that model 100% because of organisational issues, but it tries.

> OK, so you have 40 ppl working on feature X, and 40 ppl working on feature Y.

That just means that 80 people are committing to the trunk, what's the problem?

Meta's Sapling source-code management system

Posted Nov 17, 2022 22:06 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

> Branches are for bugfixes.

Not even. At least in my experience, branches are for releases. You branch at a point where the build is green, do any cherrypicks that you need, cut a release on the branch, and that's it. No merging. The branch just gets abandoned (maybe we GC it eventually?).

The corollary to this: If your code does not run at HEAD, that's your problem. You cannot make your own private branch where you use some ancient version of libfoo that nobody else is willing to support. When libfoo updates, everyone is expected to update with it, or else your code stops building (and, eventually, stops running in production). Depending on the size and reasonableness of the breakage, the people who maintain (and/or vendor) libfoo will probably be expected to help you transition to the new version, or even to do it for you, but you can't just say "we like the old version better" and expect that to end the discussion.

The corollary to the corollary: You really want to have good test coverage, because the libfoo maintainers can't be reasonably expected to find the breakage if the tests all pass (or if there are no tests).

Meta's Sapling source-code management system

Posted Nov 17, 2022 22:25 UTC (Thu) by khim (subscriber, #9252) [Link]

This is similar to crater run, I guess.

Only crater run ensures that compiler can be updated (and not other libraries) while in monorepo everything is supposed to work like that (but you can also update all the clients, which is the whole reason it's a monorepo).

Meta's Sapling source-code management system

Posted Nov 29, 2022 3:37 UTC (Tue) by brooksmoses (guest, #88422) [Link]

Yup; in my experience the "branches are for bugfixes" comes up when you need to fast-track a very specific bugfix, and so you cherrypick it onto the release branch of the existing release and then make a new release from that branch.

Meta's Sapling source-code management system

Posted Nov 29, 2022 13:59 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Hmm. We use topic branches for *all* development (there are a few exceptions; mainly automatic development version number bumps, but nothing manual). Branches for releases are `-s ours` merged into more recent branches (this preserves an "all history is reachable from HEAD" property and means we can trivially resurrect any old branch for maintenance as needed). But we also have strict vendoring rules and mangle everything to avoid conflicts with anything that could be loaded in the same process (such is life when you make SDK-like things, not end-user products).