Re: Pre-Commit Workflow
Guess it might be easier if I provide the script and associated document which I'm muttering about here :). https://docs.google.com/document/d/1z3XtAsVoCx9BDWS8itFZ0mOTd9d66tPus7eSE13m0eM It's very much a prototype - just knocked up in handful of shell scripts (I've only included a couple of the more stable ones at the moment in the Appendices - will post a couple more down the line... maybe). I may re-implement in python and extend beyond the bzr only support at some point (providing other people find it useful or another approach isn't found). AFAICT, it should be sufficient to replace bzr with svn throughout to have support there, but I haven't tested this. --diff and --overlap require interdiff from patchutils - if you don't have them installed, it should gracefully die should you attempt to use those switches. It could be greatly enhanced by the use of the reviewboard web api, but this was considered overkill and too painful for bash :). All very hokey and incomplete, but functional enough to meet my requirements. -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: Pre-Commit Workflow
On Wednesday, 19 February 2014 16:36:21 UTC+1, Allen wrote: Really good question! I also encounter the same problem. Developers dont want to wait until the previous review passed to work on the next issue. One solution I think is, once a review passed, apply that review`s patch file to a new working copy without touching what you are currently working on, then commit it. After the commit is done, you can keep going. With the script I use, I tend to work with a single checkout. There's a little bit of manual cherry picking when I initially create the first reviewboard post, but subsequently, it remembers which files are associated to the id, so the workflow goes something like: * I create a new reviewboard entry via the website (I find this easier for adding detailed descriptions, test information and assigning to another developer). * After that point, I use the script to create and upload the diff like: post id --new file1 file2 .. or entire subdirectories or other file patterns (non specification of files takes all currently modified files). This uploads the current diffs in those files to the review id (there's also a --publish switch but I tend to do a sanity check in the browser to check on whitespace, mismatching indents and so on). * Once done, and pre-review, I start working on the another patch and repeat the process - cherry picking the files which are involved in that review (this essentially disallows subsequent jobs from overlapping with the files in the first review, though there is an attempt to provide some support for that - typically, I see such tasks as blocking ones and insist on the prior review being carried out first). * During the review process, I tend to make the modifications for the id's as per the review of my colleague, and run: post id after making the suggested modifications - this just uploads the revised patch for the files associated to that review id (being a no-op if no subsequent changes have occurred). * At the point of checkin, I tend to use: bzr ci -m blah `post id --list` And this commits the changes for that id, leaving everything else alone. There are few other odds and ends in the script (and scripts which use that one :)) which assist in associating (and disassociating) files from reviews and that provide a view of changes since the last post (post id --diff for example). None of it's ideal as it's not entirely automated (and the overlapping file restrictions kinda hurts), but it works fairly well and at the very least doesn't need me to cherry pick the file list on every subsequent post, diff, checkin etc. But the pinpoint is, when you create a code review, the paths in the patch file is NOT your local path but some paths in the SVN server(I am using SVN). That prevents me to apply patches(wrong patch error). I have no idea why the review board changes the paths from local to remote server, at least it should keep the local working copy`s path. Here`s a example of what those paths look like: --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java (revision 166) +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java (working copy) you see here? The working copy is locally, but the review board still changes its path to remote server. Ah - that's interesting - I tend to pull other developers patches from the reviewboard when I'm reviewing them using: rbt patch id --print | patch -p0 and those apply to my checkouts correctly (assuming compatible branches and lack of conflicts in local mods). I tend to use a second checkout when reviewing the work of others, and resolve conflicts in my own main checkout after those have been committed (invoking post id for each of my pending reviews). The pulled patches don't have the branch reflected in the paths though - guess this could be an svn specific thing? Perhaps patch -p1 would resolve that specific issue for you? Cheers, Charlie -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: Pre-Commit Workflow
On Wednesday, 19 February 2014 21:15:31 UTC+1, David Trowbridge wrote: The typical way that other dvcs users do this is to have local branches for each piece of work, and post from each of those. I don't know enough about bzr's workflow to know if that would be appropriate (though I recall bzr branches being pretty heavyweight). Heh - well, in our case, the actual checkout itself is rather minor in the grand scheme of things - the compiled code is over a 1GB per build, so I tend to avoid having multiple checkouts where possible. Multiple builds also screw up my usage of ccache which does greatly help... providing I'm rebuilding incremental changes in the same checkout. As soon as I'm using multiple build directories, clean builds tend to get a lot slower. Cheers, Charlie -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: Pre-Commit Workflow
On Wed, Feb 19, 2014 at 7:36 AM, Allen zhangsan8...@gmail.com wrote: I have no idea why the review board changes the paths from local to remote server, at least it should keep the local working copy`s path. Here`s a example of what those paths look like: --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java (revision 166) +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java (working copy) you see here? The working copy is locally, but the review board still changes its path to remote server. Just to keep this from becoming a confusing point of discussion in this thread.. This is normal for an SVN diff. It's just a diff relative to the root of the repo, and not a remote path of any sort. This is what patch -p is made for. There's another thread already open for this, but for followers of this thread, I don't want people to get the wrong idea about anything and get stuck on this point. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: Pre-Commit Workflow
Really good question! I also encounter the same problem. Developers dont want to wait until the previous review passed to work on the next issue. One solution I think is, once a review passed, apply that review`s patch file to a new working copy without touching what you are currently working on, then commit it. After the commit is done, you can keep going. But the pinpoint is, when you create a code review, the paths in the patch file is NOT your local path but some paths in the SVN server(I am using SVN). That prevents me to apply patches(wrong patch error). I have no idea why the review board changes the paths from local to remote server, at least it should keep the local working copy`s path. Here`s a example of what those paths look like: --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java (revision 166) +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java (working copy) you see here? The working copy is locally, but the review board still changes its path to remote server. -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: Pre-Commit Workflow
The typical way that other dvcs users do this is to have local branches for each piece of work, and post from each of those. I don't know enough about bzr's workflow to know if that would be appropriate (though I recall bzr branches being pretty heavyweight). -David On Feb 15, 2014, at 12:51 PM, Charles Yates charles.ya...@gmail.com wrote: Hi, We're trying to follow a pre-commit workflow with bzr with all patches submitted to the review board prior to checkin to the repo - I was wondering anyone had any experience with this and how best to handle pending patches. Sometimes it's inconvenient to wait for the review process to be completed before working on another part of the code - as a result, I can have a few patches pending and cherry picking the right files from the checkout to manually create a diff can be quite time consuming and error prone when there are a handful of small review posts pending. I've written a quick and dirty script which associates specific files with a review ticket and provides me with a view of changes which have been made on those files since the last posting - it also allows the files included to be manipulated from the command line and post the current patches as required. I'm quite sure it can be improved upon and would be happy to provide a link to it if anyone is curious (or just wants to point and laugh :p). I was wondering if there were other ways to handle this - I was vaguely thinking about using some kind of local repo, tagging each checkin comment with the associated review id and creating review posts from that, but it would still involve some kind of manual cherry picking process when handling merges from other developers. With the tool I have, the latter tends to be a bit of a non-issue as I just need to make the corrections, and run my script against each of my pending reviews and it does the rest (with the exception of patches which pending patches which touch the same source files - those tend to block me until the previous review is cleared up). Possibly over thinking the issue :-) - any suggestions welcome. Cheers, Charlie -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out. -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups reviewboard 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/groups/opt_out.
Re: pre-commit workflow
Is there any documentation for this post-review script? Where should this script run? In my case we are using a linux server for review-board and have windows-client where we are working on our code (svn working base is on windows). Does this script fit into this environment? Do I have the possibility to connect via ssh and work with the post- review script? Another alternative could be a REST webservice for review-board to upload new reviews?! ~ Bernd On 12 Feb., 18:26, Jeff Andros j...@bigredtj.com wrote: 2009/2/12 Brot schla...@gmail.com Hello, today I installed Reviewboard and now I have a few questions. 1) Is there a possibility to create reviews from the command-line or in scripts? It's not really handy to upload the diff-file for every review. The manual way wouldn't get acceptance and the developers will not use reviews. Yup! there's a script called post-review... I think for now you have to get it from SVN, but Christian is working on packaging this for easy_install 2) If a developer accepts an review, is there a way to commit the reviewed diff automatically? Not by default... that's a job for your SCM...although the forthcoming extensions might make that possible... or you might be able to use the API to have a daemon search for shipit tags and submit for you ~ Bernd -- Jeff O|||O --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
