7 ms·

> CTC creates a Merkle-style tree... You call it Merkle-style tree despite the fact it is obviously a DAG? -- Edit: > Large changes are also more prone to o

> CTC creates a Merkle-style tree... You call it Merkle-style tree despite the fact it is obviously a DAG? -- Edit: > Large changes are also more prone to outages. If we land them outside the working hours, there would be limited resources to mitigate potential outages. To prevent this, we ended up asking engineers to get up early to deploy these changes Huh, landing changes to HEAD and releasing to production are not decoupled?

fnord123 4y ago
> You call it Merkle-style tree despite the fact it is obviously a DAG? All trees are DAGs so that's not really adding much.
- progbits 4y ago
  But not all DAGs are trees and the one in the picture (and generally all graphs of dependencies) isn't.
  - nl 4y ago
    It's a multirooted tree. And describing it as a Merkle-style tree conveys additional implementation about the implementation - presumably the tree stores the hash ("computed from all of its source files and inputs") which just saying "it's a DAG" doesn't tell you.
    - dymk 4y ago
      Calling it a Merkle style DAG would have solved the issue. Or just avoid the fancy names and call it what it is: they walk the dependency graph to identify build targets that have a changed dependency.
ZephyrBlu 4y ago
DAG doesn't seem like a useful identifier here since seems like a DAG encompasses many different types of trees, and in this case the specific data structure is closer to a Merkle tree than a generic DAG.
bpicolo 4y ago
They have a paper on that release process https://eng.uber.com/research/keeping-master-green-at-scale/ https://eng.uber.com/research/keeping-master-green-at-scale/
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
dan-robertson 4y ago
Their point is that they attach data to nodes (data(node) = hash(node + (data(c) for each child c of node))) and can therefore compare hashes at the roots[1] to quickly determine which dependencies have changed and whether changes clash. Perhaps you’re complaining about it not being a tree because there can be multiple roots which seems fair enough. [1] I think there are many ‘roots’ as roots are going to be leaf build targets like various executables or test results

fnord123 4y ago

> You call it Merkle-style tree despite the fact it is obviously a DAG? All trees are DAGs so that's not really adding much.

progbits 4y ago
But not all DAGs are trees and the one in the picture (and generally all graphs of dependencies) isn't.
- nl 4y ago
  It's a multirooted tree. And describing it as a Merkle-style tree conveys additional implementation about the implementation - presumably the tree stores the hash ("computed from all of its source files and inputs") which just saying "it's a DAG" doesn't tell you.
  - dymk 4y ago
    Calling it a Merkle style DAG would have solved the issue. Or just avoid the fancy names and call it what it is: they walk the dependency graph to identify build targets that have a changed dependency.

ZephyrBlu 4y ago

DAG doesn't seem like a useful identifier here since seems like a DAG encompasses many different types of trees, and in this case the specific data structure is closer to a Merkle tree than a generic DAG.

bpicolo 4y ago

They have a paper on that release process https://eng.uber.com/research/keeping-master-green-at-scale/ https://eng.uber.com/research/keeping-master-green-at-scale/

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

dan-robertson 4y ago

Their point is that they attach data to nodes (data(node) = hash(node + (data(c) for each child c of node))) and can therefore compare hashes at the roots[1] to quickly determine which dependencies have changed and whether changes clash. Perhaps you’re complaining about it not being a tree because there can be multiple roots which seems fair enough. [1] I think there are many ‘roots’ as roots are going to be leaf build targets like various executables or test results