Today we've open sourced revup, a commit-based code review tool that we've been using internally at Skydio for the last year and a half.
The goal of revup is to make it incredibly easy to manage and upload code reviews. Revup's powerful model allows for multiple chains of dependent and independent reviews to be developed on a single working branch. At upload time, revup will create all necessary branches for you in the background without touching your working files. Independent changes can be merged independently through the github interface or with whatever CI your repository uses.
On top of that, revup provides more features, including
- Managing reviewers and labels
- Adding graphs / tables to PRs to track dependencies and upload history
- Rebase detection to save time and CI cost
- Many more! see the README and documentation
I'm interested, but confused. I feel like I need either a more complete example of the workflow (writing code -> reviewing -> rewriting my history -> merging) or a deeper dive into how this works.
Will the same commit ever appear in two pull requests managed by Revup?
Does this take every commit in a "topic", cherry-pick it to a Revup-managed branch under the hood, and create a pull request for that topic?
If so, how can you safely merge these branches if they differ significantly from the one that the developer is testing on? or do you just rely on continuous integration? or do you wait until all topics that share a history have passed review?
Do you run into problems where PR comments get deleted after amending the history and re-pushing?
>I feel like I need either a more complete example of the workflow (writing code -> reviewing -> rewriting my history -> merging) or a deeper dive into how this works.
Have you tried the tutorial? It's only missing the reviewing + merging, but that can be done in github UI just like a normal PR.
>Will the same commit ever appear in two pull requests managed by Revup?
No, github will show just the commits in that pull request but not in its target branch/pr
>Does this take every commit in a "topic", cherry-pick it to a Revup-managed branch under the hood, and create a pull request for that topic?
Yep
>If so, how can you safely merge these branches if they differ significantly from the one that the developer is testing on? or do you just rely on continuous integration? or do you wait until all topics that share a history have passed review?
One of the biggest advantages of working this way is that changes can merge as soon as each one is ready / reviewed. CI definitely helps, but mainly we rely on the author's awareness of interdependencies between their changes. It's certainly possible to get unexpected behavior, but after thousands of PRs with this workflow it hasn't caused any problems.
>Do you run into problems where PR comments get deleted after amending the >history and re-pushing?
Even after force pushing, github will still show old comments
It's a really interesting idea. The multi-PR workflow I was used to in Facebook's Phabricator required a lot of commit reordering to get things ready for review. Having separate review branches (topics) from dev branches seems like a nice alternative.
I still think there could be something earlier or more explicit in the README to explain the general idea of cherry-picking commits from a dev branch to review branch to split out convenient independent units to review and merge separately. Without running the tutorial, I wasn't really sure that's what the goal was.
The goal of revup is to make it incredibly easy to manage and upload code reviews. Revup's powerful model allows for multiple chains of dependent and independent reviews to be developed on a single working branch. At upload time, revup will create all necessary branches for you in the background without touching your working files. Independent changes can be merged independently through the github interface or with whatever CI your repository uses.
On top of that, revup provides more features, including - Managing reviewers and labels - Adding graphs / tables to PRs to track dependencies and upload history - Rebase detection to save time and CI cost - Many more! see the README and documentation
You can pip install and upload your first changes in minutes. Check it out at https://github.com/Skydio/revup