In CodeFlow any comment is a floating object with a line connecting it to whatever selection it was created for and you can move it around as you like. You also can easily filter out visible comments by state, author, participation in them.. Features around comparing iterations, marking already reviewed files and similar are the same as far as I remember.
Another reason for my opinion might also be that CodeFlow is probably better optimized for large screens, but this might be caused by the weird Google standard of 80 column limit for source code which I will just never understand in the 21st century where everyone has 24" and up full HD to 4k screens.
I am comparing state of both from 2015 where I worked with both in the same year.
even if you have a big screen, it's still useful to be able to fit two or three files side by side on a single screen. 80 chars might not make sense as a hard requirement for, eg, a c++ codebase, but it's still a worthy ideal to shoot for.
The toolkit is very small and lacks good definition of elements (both visually in that it lacks contrast, and practically in that I have no idea what is clickable or editable).
The page structure isn't that clear either, where are the column headings? And on my widescreen browser window the isn't a limit on horizontal stretch - I have to play with the browser to find a good width. Also, I can expand code, but how do I shrink/hide it?
And no, you can't shrink/hide code, other than by re-diffing. What can I say -- it's surprisingly hard to implement and didn't seem worth it.
GitHub: 31M users
BitBucket: 6M users, 1M orgs
GitLab: 100K orgs
The GitLab number tallies with Emily's answer, which gives me some moderate confidence that these numbers are in the right neighborhood. I'm also going to assume that the users-vs-teams numbers are all in roughly the same proportion.
Based one these numbers it doesn't make much sense to target BitBucket unless either 1) they're growing much faster than GitHub (unlikely) or 2) their customers are a much better fit for Reviewable (possible, but it would have to be a truly significant difference in userbase composition). Targeting GitLab doesn't appear to make sense at all (as a business), though perhaps they're growing fast.
Is what makes me uncomfortable about modern webdev. Valuable product work constantly deprioritized by migrations to new frameworks. Magpieing has always been a risk in hobby projects, but in the past there was a smaller torrent of nee things to always be migrating to.
Amazing tool. Great integration with version control, code search, continuous integration.
Disclaimer: I work for Alphabet.
but it gets worse. the UI can't or won't do trivial rebases. so either you upload a new, rebased revision, and get the reviewers to re-review (because stale reviews get wiped), or just rebase, push, and mark as merged. i get you are supposed to review rebases, but this can grind a team to a halt. you're waiting for approvals, but by the time you get them someone else has pushed a new change... a colossal waste of time (edit: especially if you require 2 approvals, which i do think is good practice, and some AWS teams do it).
this also means people are trained to ignore the merge button or expect it to be greyed out. but it might be greyed out for other reason though. in GitHub, you have big green check-marks or red icons to indicate which conditions have and haven't been met (reviewers, CI, merge conflicts). in CRUX, hovering over the greyed out merge button gets you one cause at best (there is a page/tab that shows more detail, but almost nobody looks at it).
obviously it depends on your team, but it requires near constant vigilance to maintain high quality with CRUX, especially with a big team or less experienced devs contributing. process is supposed to make quality easier, not harder!
there are many other smaller issues, but that's the big one IMO. as for ReviewBoard, personally i prefer Gerrit, which itself doesn't have a great UI, but makes up for it in the workflow.
I personally love the Crux tool and some of its add ons.
As detailed, that only prevents merging via the UX, not pushes to the main branch. Maybe the team does suck, but I still consider it a shortcoming of CRUX et al.
Lots of people have worked for both Google and Microsoft. The article said CodeFlow was good. You said no, Critique is better! But I guess you don’t actually know one way or the other.
Which is too bad. Because it’d be great to hear thoughts from people who’ve tried both.
The way we do things is the right way because that's what we do. Any disagreement is ignorance.
Nope, I did not. I just said that people really want Critique, which they do. Even CodeFlow itself is evidence of that.