3 ms·

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

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.

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.