I wonder who will be the first to break, swallow the eventual consistence pill, and remember that both Monotone and Mercurial track branches in a way that allows multiple heads, which avoids full-linearisation requirement. I prefer Monotone’s «global branch names, so you cannot avoid multiple heads» approach for small-scale workflow reasons too, but it also hits the nail on the head for a slightly catastrophic scaling-out scenario.
FWIW, I think server-side rebases with the Bonsai model allow you to have a total linear order on main very efficiently. This is what we called “push rebase” – the original version was done within Mercurial, using files on disk and the Mercurial data model. Mononoke’s contribution here was to implement push rebases efficiently using the Bonsai model, in the context of a stateless server built on top of an object store. As you’ve been able to tell, Bonsai changesets and efficient push rebases were carefully designed to work together and scale up (they’ve scaled up just fine to an order of magnitude beyond the original design parameters).
Linearity still forces one to have a mutex for updating the head position, no? Although with good design it can scale up very well (out, that’s harder)
(Also rebases lie about what was tested, but fortunately nobody ever reads history to see those lies)
Yes. The goal of the Bonsai data model is to make that critical section as small, and involve as few pointer chases, as possible.
Agreed that push rebases don’t detect semantic merge conflicts across files (they worked at the file and directory level). In massive monorepos this isn’t a major problem though, especially because work would generally be done against the latest “warm” bookmark, which meant a bookmark for which the build system had already verified things and cached build results.
I wonder who will be the first to break, swallow the eventual consistence pill, and remember that both Monotone and Mercurial track branches in a way that allows multiple heads, which avoids full-linearisation requirement. I prefer Monotone’s «global branch names, so you cannot avoid multiple heads» approach for small-scale workflow reasons too, but it also hits the nail on the head for a slightly catastrophic scaling-out scenario.
score 1 · canonical
FWIW, I think server-side rebases with the Bonsai model allow you to have a total linear order on main very efficiently. This is what we called “push rebase” – the original version was done within Mercurial, using files on disk and the Mercurial data model. Mononoke’s contribution here was to implement push rebases efficiently using the Bonsai model, in the context of a stateless server built on top of an object store. As you’ve been able to tell, Bonsai changesets and efficient push rebases were carefully designed to work together and scale up (they’ve scaled up just fine to an order of magnitude beyond the original design parameters).
score 1 · canonical
Linearity still forces one to have a mutex for updating the head position, no? Although with good design it can scale up very well (out, that’s harder)
(Also rebases lie about what was tested, but fortunately nobody ever reads history to see those lies)
score 1 · canonical
Yes. The goal of the Bonsai data model is to make that critical section as small, and involve as few pointer chases, as possible.
Agreed that push rebases don’t detect semantic merge conflicts across files (they worked at the file and directory level). In massive monorepos this isn’t a major problem though, especially because work would generally be done against the latest “warm” bookmark, which meant a bookmark for which the build system had already verified things and cached build results.
score 1 · canonical