3 ms·

Gerrit, the review system Chromium uses does support the exact feature of committing across repo boundaries using "Topics" . You can verify a "Topic" is atomica

Gerrit, the review system Chromium uses does support the exact feature of committing across repo boundaries using "Topics" . You can verify a "Topic" is atomically submittable across repositories before submission and then commit it to those repos all at the same time. https://www.gerritcodereview.com/releases/2.12.md#New-Features https://www.gerritcodereview.com/releases/2.12.md#New-Featur...

iainmerrick 10y ago
Sounds good! Although it says: "This setting should be considered experimental, and is disabled by default" I assume all the repos involved have to be managed by the same Gerrit instance too. In that case it's not clear to me what you actually gain from multiple repos (besides working around Git's scaling issues).
- jamesmiller5 10y ago
  If I'm not mistaken it's turned on by default in the latest 2.13.5 version, though I haven't had a chance to play with it much other than a quick smoke test. > In that case it's not clear to me what you actually gain from multiple repos (besides working around Git's scaling issues). I'm not sure what you mean here, would you please elaborate?
  - iainmerrick 10y ago
    If you have 100 repos (say) with all code reviews and commits going through Gerrit, how is that different in practice from having a monorepo? Why would you want or need multiple repos? If you're pulling in repos from third parties, outside of your Gerrit workflow, that's different -- but in that case I don't see how you can enforce those atomic multi-repo commits.
    - luckydude 10y ago
      I dunno about Gerrit, but in BitKeeper, a commit that spans multiple repos is atomic, it either works or is completely rolled back (yes, of course, if there is a damaged disk and you can't write the data I'm lieing but if it is possible to be atomic it is atomic). We lock the top repo and then go do the work in the subrepos. All repos respect a lock in the top repo but we have a way to say "yeah, yeah, there is a lock but that is your lock, go ahead".

iainmerrick 10y ago

Sounds good! Although it says: "This setting should be considered experimental, and is disabled by default" I assume all the repos involved have to be managed by the same Gerrit instance too. In that case it's not clear to me what you actually gain from multiple repos (besides working around Git's scaling issues).

jamesmiller5 10y ago
If I'm not mistaken it's turned on by default in the latest 2.13.5 version, though I haven't had a chance to play with it much other than a quick smoke test. > In that case it's not clear to me what you actually gain from multiple repos (besides working around Git's scaling issues). I'm not sure what you mean here, would you please elaborate?
- iainmerrick 10y ago
  If you have 100 repos (say) with all code reviews and commits going through Gerrit, how is that different in practice from having a monorepo? Why would you want or need multiple repos? If you're pulling in repos from third parties, outside of your Gerrit workflow, that's different -- but in that case I don't see how you can enforce those atomic multi-repo commits.
  - luckydude 10y ago
    I dunno about Gerrit, but in BitKeeper, a commit that spans multiple repos is atomic, it either works or is completely rolled back (yes, of course, if there is a damaged disk and you can't write the data I'm lieing but if it is possible to be atomic it is atomic). We lock the top repo and then go do the work in the subrepos. All repos respect a lock in the top repo but we have a way to say "yeah, yeah, there is a lock but that is your lock, go ahead".