[guitarbill]

There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity.

I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restricted creation of streams, meaning you simply could not branch at all if I'm remembering), and the capability to stash changes/switch branches to work on different work items if one was blocked was also more cumbersome. Code review was terrible.

A centralised paradigm does simplify things a lot mentally, but the workflow suffers IMO.

[hnthrowaway919]

You certainly make some good points about the downsides of RTC. RTC's streams are often compared to git's branches because they're the closest construct, but they are definitely very different and have pretty minimal overlap, considering they're basically the parallel construct. IMO stashing changes was not bad (suspending change sets, I believe it was called), but perhaps I was mostly doing that within 1 stream and not between streams. I agree that code review was not great, though I'm not a _huge_ fan of GitHub's comment/PR review mechanism either. I'm not aware of code reviewing built in to git itself, though I could be totally missing it.

[guitarbill]

> I'm not aware of code reviewing built in to git itself

I guess you can pull a branch or email a patch and diff it with the diff tool of your choice.

There's a few options for gir review UIs, e.g. Gerrit or GitLab. Kind of unix-y, just have the VCS be a good VCS.