7 ms·

How is it an improvement over the monorepo? The article claims it is but doesn't say how.

nickm12 6y ago
The main power of Brazil is that every buildable unit ("package" in Brazil) can have multiple branches and then a software stack can be defined in terms of the set of branches ("version set" in Brazil) across all the software in the stack. The "version set" defines the complete build, test, and runtime closure of the application. In that sense, a version set is very much like a branch in a monorepo. The difference is that version sets are more composable and a version set contains only a subset of the repo. Like branches, version sets can have an upstream version set, so a common pattern is to have three layers of version sets: the central one (called "live" at Amazon) which contains your build tools, open source packages etc.; a shared platform version set which contains code shared across many applications; and then a number of downstream application version sets.
- solipsism 6y ago
  Thanks, but that's what was in the article. Why is this better than monorepo, specifically? What use cases does it allow that aren't possible in a monorepo? BTW, the typically talked about giant monorepos do support branching, and the branch is never the entire repo.
  - nickm12 6y ago
    A branch in a git repository defines a snapshot of the entire repository. You can't have two branches checked out simultaneously. If your repository has a file at a path, you can't have some part of the repository depending on that file at revision A and some other part of the repository depending on that file at revision B. Version Sets let you do that.
    - solipsism 6y ago
      Not everything is git. Subversion lets you do that. So does perforce. And of course Google's monorepo has its history in perforce. Again... People making this claim that Brazil is so much better than monorepos seem to know a lot about Brazil but not much about monorepos.
      - nickm12 6y ago
        Brazil was originally built on a Perforce monorepo. It didn't start being git until 2013 or so and even then packages could migrate between the Perforce repository and git repository. So Brazil is not an alternative to a monorepo.
donavanm 6y ago
It starts with a distributed approach, from the bottom up. The primitives of Packages and Version Sets match how teams are organized and work. Package versions, VFIs, and package builds are the interfaces & immutable artifacts for teams and software stacks to interact. Conversely the the monorepo approach seems to spend its time trying to serialize and separate the innate codependencies of its approach.
- solipsism 6y ago
  Package versions, VFIs, and package builds are the interfaces & immutable artifacts for teams and software stacks to interact. That doesn't explain anything, it's just a bunch of terms. Monorepos have lots of terms too. Why is it so hard to explain? I suspect it's because people claiming one is better than the other are only familiar with one, so they can't actually back up that claim.

The main power of Brazil is that every buildable unit ("package" in Brazil) can have multiple branches and then a software stack can be defined in terms of the set of branches ("version set" in Brazil) across all the software in the stack. The "version set" defines the complete build, test, and runtime closure of the application. In that sense, a version set is very much like a branch in a monorepo. The difference is that version sets are more composable and a version set contains only a subset of the repo. Like branches, version sets can have an upstream version set, so a common pattern is to have three layers of version sets: the central one (called "live" at Amazon) which contains your build tools, open source packages etc.; a shared platform version set which contains code shared across many applications; and then a number of downstream application version sets.

solipsism 6y ago
Thanks, but that's what was in the article. Why is this better than monorepo, specifically? What use cases does it allow that aren't possible in a monorepo? BTW, the typically talked about giant monorepos do support branching, and the branch is never the entire repo.
- nickm12 6y ago
  A branch in a git repository defines a snapshot of the entire repository. You can't have two branches checked out simultaneously. If your repository has a file at a path, you can't have some part of the repository depending on that file at revision A and some other part of the repository depending on that file at revision B. Version Sets let you do that.
  - solipsism 6y ago
    Not everything is git. Subversion lets you do that. So does perforce. And of course Google's monorepo has its history in perforce. Again... People making this claim that Brazil is so much better than monorepos seem to know a lot about Brazil but not much about monorepos.
    - nickm12 6y ago
      Brazil was originally built on a Perforce monorepo. It didn't start being git until 2013 or so and even then packages could migrate between the Perforce repository and git repository. So Brazil is not an alternative to a monorepo.

donavanm 6y ago

It starts with a distributed approach, from the bottom up. The primitives of Packages and Version Sets match how teams are organized and work. Package versions, VFIs, and package builds are the interfaces & immutable artifacts for teams and software stacks to interact. Conversely the the monorepo approach seems to spend its time trying to serialize and separate the innate codependencies of its approach.

solipsism 6y ago
Package versions, VFIs, and package builds are the interfaces & immutable artifacts for teams and software stacks to interact. That doesn't explain anything, it's just a bunch of terms. Monorepos have lots of terms too. Why is it so hard to explain? I suspect it's because people claiming one is better than the other are only familiar with one, so they can't actually back up that claim.