Hi all! I'm currently trying to develop the code-review and issue tracking system for the company for which I work, and having spent (many...) hours scoping the market it seems that Review Board is the best choice for us - yay! We currently use MantisBT for bug-tracking, which serves us very well, and we would be reluctant to move away from this. We're currently using Subversion as our CVS - this is (slightly) more open to change but again, we'd ideally like a workflow that works with this natively.
That said, I'm struggling slightly to replicate our desired workflow within RB, and I'd really appreciate some guidance on whether what I would like to do is possible or whether some other workflow will need to be developed. The desired workflow is as follows: 1. The developer or manager raises a MantisBT ticket 2. The MantisBT ticket is assigned to a developer 3. Developer creates a server-side copy of SVN_ROOT/trunk/ in a separate development branch, SVN_ROOT/branches/_Developers/USERNAME/_something_something_ and names it something sensible 4. Developer develops (hopefully...) and commits incremental changes to their dev branch. These incremental commits don't need reviewing. 5. Developer finishes development process, and has a fully updated branch that they would like to put forward for merging into trunk. As a final step, they merge trunk into their branch and resolve any conflicts, in case some development has happened in the meantime that affects an area that they have also touched. From here, we'd really like this next section to be as automated as possible! 6. By some mechanism, the review process is triggered - the initial concept was to have this done via a commit to the branch with a special tag, but having thought about this it doesn't really make sense - if development is finished what is it that we're committing? - so some other mechanism to trigger can also be used. 7. A diff is generated between the dev branch and trunk. As the developer has previously merged trunk into their branch, this diff will contain only the sum of all changes proposed by the developer 8. This diff is uploaded to RB as the diff of a new review request. (At the same time some other administrative faff should happen, like a link to this review being posted as a note on the MantisBT ticket, but that's somewhat inconsequential to the RB process). 9. This is reviewed, revised, and diffs reuploaded as necessary. 10. Eventually, this is accepted. Trunk should be merged into the branch one more time to ensure no conflicts have been set up during the review process, and finally the branch is merged into trunk. The issue that I'm coming into, specifically, is in step 8; when trying to use the RBTools Python bindings to upload this generated diff, I'm coming up with the error basedir: This field is required On investigation, this appears to be due to RB's reluctance to accept a diff between branches - and therefore implicitely a diff between two files in different locations - rather than a diff between revisions of the same file in the same location. Obviously, this is a somewhat key feature for us and something that, without, we'd have to change our workflow. Does anyone have any ideas on either a) how to achieve what we're looking to do, or b) how the workflow that we're going for could be modified to be compatible with the workflow that RB expects? I'm really keen to introduce RB as I do think it's the most flexible tool I've come across for this purpose and it is almost unrivalled in its extensibility, but I'm just struggling with this workflow at the moment and could really do with some guidance. Hope you're all well! -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "Review Board Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
