Re: post-commit with revision-range
> So with this process, you want to continually > update an existing review request, and you want it to incorporate the new > updates alongside the existing ones? So if it's already created with a diff > modifying 5 files, the next update that adds 2 files will result in a diff > containing a total of 7? Yep! Exactly. > So that won't happen today unless that revision range spans the revision > originally modifying those 5. Right. I'm getting around this by automatically publishing the review when it gets created or updated. That seems to be working, and I'm actually happy about the way that works. Since I'm writing the plugin for Hudson, when a build runs, it creates or updates a review request and then publishes it. This way the review request emails get sent out and the author knows when it's been done. Otherwise they wouldn't know to go into RB and manually publish it. So, I'm ok with this process currently and think that in an automated process like what I'm doing, updating a diff with new files would defeat the purpose of automation because it would still require a manual step that I want to avoid. > Going to be working toward expanding RBTools to make it easier to write > custom scripts such as > this, so maybe it'd be better there? Yeah, I'd agree. I know you're currently developing some APIs and hooks, but in the interim I've developed a Java API that calls your RESTful endpoints with the proper params and authentication to update fields and publish reviews. Works fine for me for the moment. Thanks for following back up! -Ryan -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
Re: post-commit with revision-range
Hi Ryan, Been out of town the past few days, so I'm catching up on e-mail now. Okay, so I think I understand. So with this process, you want to continually update an existing review request, and you want it to incorporate the new updates alongside the existing ones? So if it's already created with a diff modifying 5 files, the next update that adds 2 files will result in a diff containing a total of 7? So that won't happen today unless that revision range spans the revision originally modifying those 5. If you post a review request with a range that covers one set of files, and then update it with a diff covering another set of files, then the latest diff will only contain that second set. The first set will still exist as a revision, but won't be the latest shown. It might be possible to come up with something a bit more custom to augment the existing diff, but I don't know how clean it would be right now. You'd have to download the existing diff, figure out what should be removed/appended/replaced, and update that. I don't think augmenting the latest diff is a very common scenario. If it turned out to be easy (unlikely without the new APIs I'm doing for 1.5 and without parsing the downloadable diff file) then maybe we could add it to post-review, but it might be best as its own tool. Going to be working toward expanding RBTools to make it easier to write custom scripts such as this, so maybe it'd be better there? Please let me know if I misunderstood. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Tue, Mar 30, 2010 at 3:30 PM, rshelley wrote: > Ok, let me clarify with a concrete scenario. > > We use JIRA for our bug tracking. JIRA generates bug IDs such as > "BUG-123". We also have Hudson for continuous integration, and it's > tied to Perforce to poll for changes, build the changes, and log the > changelists in the build (for release notes). Our standard process is > to include within our Perforce descriptions the JIRA bug ID our check- > in is for, so Perforce syncs with JIRA to update the issue with the > Perforce files modified to complete the circle. So now we know what > files were changed to fix what bugs in which build (and in reverse, > what build certain changes were included in by reference through > JIRA). > > There are many, many, MANY times where one check-in (and therefore, > one changelist) does not encompass all of the changes required to > resolve the bug, but all changes are tracked by a single JIRA. We > have a culture of checking-in often and not holding onto files for > days on end until we check-in one massive changelist since we're > developing in a highly collaborative and volatile environment (we > often have people developing within the same file at the same time, so > merges are often done on a daily basis). This is why we use CI to > build and test the project regularly. So it doesn't make sense for us > to create dozens of new review requests for new changelists since they > are often updates to a related JIRA. > > Now, we're both in agreement that the CLI provides all the > functionality of creating and updating reviews and the developer can > decide what files update what reviews and when to create a new > review. However, I can't get my developers to use it. Both Kyle > Hayes and I have been expounding it, documenting it internally, > emailing our team, and we haven't had a single person use it yet. And > until I have something people will use (or even better, in their view, > is if it's done for them), I can't make it a standard. > > So my goal is to create a Hudson plugin to link Perforce and > Reviewboard for post-commit reviews. Now, I know that Reviewboard has > a field for Bugs, which we currently have linked to JIRA, but I'm not > aware of a way to pass that in as part of post-review, or retrieve > through a CLI query, so I'm looking into mapping a Perforce > changelist, to a JIRA bug (via the bug ID entered in the changelist > description) and the Reviewboard ID. This mapping should be > relatively trivial. What isn't trivial is making updates to a review > request when an updated changelist is submit (meaning a second > changelist is submit with the same JIRA bug ID as another changelist > that has an open review request). This is where my Improvement > request 1562 would have been helpful. > > From what I gather in your post, however, is that "revision-range" > isn't supported by post-review for Perforce which shouldn't be a > problem. Hudson gives me the depot paths as part of the change set > the build was executed for. I just want to make sure that if I have 5 > files in the review, and I add 2 and update 3 that the review shows 7 > files with three deltas and the other 3 files that were in the > original review aren't dropped. > > I hope that makes sense and isn't too confusing. I know post-commit > is a less-than-ideal solution. I'm pro-pre-
Re: post-commit with revision-range
Ok, let me clarify with a concrete scenario. We use JIRA for our bug tracking. JIRA generates bug IDs such as "BUG-123". We also have Hudson for continuous integration, and it's tied to Perforce to poll for changes, build the changes, and log the changelists in the build (for release notes). Our standard process is to include within our Perforce descriptions the JIRA bug ID our check- in is for, so Perforce syncs with JIRA to update the issue with the Perforce files modified to complete the circle. So now we know what files were changed to fix what bugs in which build (and in reverse, what build certain changes were included in by reference through JIRA). There are many, many, MANY times where one check-in (and therefore, one changelist) does not encompass all of the changes required to resolve the bug, but all changes are tracked by a single JIRA. We have a culture of checking-in often and not holding onto files for days on end until we check-in one massive changelist since we're developing in a highly collaborative and volatile environment (we often have people developing within the same file at the same time, so merges are often done on a daily basis). This is why we use CI to build and test the project regularly. So it doesn't make sense for us to create dozens of new review requests for new changelists since they are often updates to a related JIRA. Now, we're both in agreement that the CLI provides all the functionality of creating and updating reviews and the developer can decide what files update what reviews and when to create a new review. However, I can't get my developers to use it. Both Kyle Hayes and I have been expounding it, documenting it internally, emailing our team, and we haven't had a single person use it yet. And until I have something people will use (or even better, in their view, is if it's done for them), I can't make it a standard. So my goal is to create a Hudson plugin to link Perforce and Reviewboard for post-commit reviews. Now, I know that Reviewboard has a field for Bugs, which we currently have linked to JIRA, but I'm not aware of a way to pass that in as part of post-review, or retrieve through a CLI query, so I'm looking into mapping a Perforce changelist, to a JIRA bug (via the bug ID entered in the changelist description) and the Reviewboard ID. This mapping should be relatively trivial. What isn't trivial is making updates to a review request when an updated changelist is submit (meaning a second changelist is submit with the same JIRA bug ID as another changelist that has an open review request). This is where my Improvement request 1562 would have been helpful. >From what I gather in your post, however, is that "revision-range" isn't supported by post-review for Perforce which shouldn't be a problem. Hudson gives me the depot paths as part of the change set the build was executed for. I just want to make sure that if I have 5 files in the review, and I add 2 and update 3 that the review shows 7 files with three deltas and the other 3 files that were in the original review aren't dropped. I hope that makes sense and isn't too confusing. I know post-commit is a less-than-ideal solution. I'm pro-pre-commit, but my team is not. Well, they're not even really pro-review, but that's going to change, and I need to start somewhere. So, unless I make it easy or transparent to them, they will keep pushing back. For the time-being, some review is better than no review! -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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 To unsubscribe, reply using "remove me" as the subject.
Re: post-commit with revision-range
Hi, So I'm not 100% sure I understood correctly, but I assume this is related to the bug you just filed. --revision-range is not supported on Perforce, but equivalent functionality does exist. You can use the Perforce path syntax containing revision ranges, as shown here: http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/#posting-paths With this syntax, you wouldn't specify a change number, which is probably ideal here. Review Board has a one-to-one mapping of review requests and change numbers. You can't use the same change number on multiple review requests, and one review request can't represent multiple change numbers. So what you'd do is use the path syntax along with -r to update an existing review request. The newly created diff will be shown as a new diff revision in the diff viewer. This is fine so long as it actually is a new iteration on the work already done for that review request. The rest is where you lost me. I don't quite get what you're trying to do with -r. The fact that you're concerned about files differing in the changelists makes me wonder. Are you looking to just basically reuse the same review request for multiple, different changes? If so, that's probably not what you're going to want to do. However, if it is just, say, a new commit to a branch for a specific feature, then that's probably okay. It should handle it, and I wouldn't expect deletes unless there actually was a delete within that range. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Tue, Mar 30, 2010 at 9:47 AM, rshelley wrote: > Since we haven't yet been able to get post-commit working, I'm trying > to develop around the eventuality that it will be working in the > foreseeable future. Since I can't test it successfully at the moment, > I'd like to see what the expected functionality would be for revision- > ranges with post-commit if I execute post-review with the "-r" option > but with different changelist numbers where the files between > changelists are different (I make a change to file1, submit, create > review, then change file2, submit, update review). Does it aggregate > changes (in the example, file1 and file2 now show changes), or assume > deletes (in the example, shows as a delete for file1)? Knowing this > shapes how I map and store changelist/revision number/external > reference ID values. Thanks! > > -- > Want to help the Review Board project? Donate today at > http://www.reviewboard.org/donate/ > Happy user? Let us know at http://www.reviewboard.org/users/ > -~--~~~~--~~--~--~--- > 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 > > To unsubscribe from this group, send email to reviewboard+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject. > -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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 To unsubscribe from this group, send email to reviewboard+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
post-commit with revision-range
Since we haven't yet been able to get post-commit working, I'm trying to develop around the eventuality that it will be working in the foreseeable future. Since I can't test it successfully at the moment, I'd like to see what the expected functionality would be for revision- ranges with post-commit if I execute post-review with the "-r" option but with different changelist numbers where the files between changelists are different (I make a change to file1, submit, create review, then change file2, submit, update review). Does it aggregate changes (in the example, file1 and file2 now show changes), or assume deletes (in the example, shows as a delete for file1)? Knowing this shapes how I map and store changelist/revision number/external reference ID values. Thanks! -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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 To unsubscribe from this group, send email to reviewboard+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: fail to post-commit with --revision-range
Hi. Sorry for the late reply on this. I'm out of town and am less responsive than I usually am. So, it looks like you modified the ClearCaseClient part. Is that what you intended? I gathered you're using CVS. The ClearCaseClient part is definitely wrong, so we want to fix that. I'm looking at the code and, as far as I can tell, it's doing exactly what it should be doing. I don't see how we'd be losing a space in that. What version of post-review and RBTools are you using? Perhaps this has since been fixed. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.review-board.org VMware, Inc. - http://www.vmware.com On Tue, Jun 2, 2009 at 8:45 AM, sailor...@gmail.com wrote: > > I tried to make a change as below. > 546c546 > < rev_str += "-r %s" % rev > --- > > rev_str += " -r %s" % rev > > It seems this Python code is not too complex, I will try to customize > it later. > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: fail to post-commit with --revision-range
I tried to make a change as below. 546c546 < rev_str += "-r %s" % rev --- > rev_str += " -r %s" % rev It seems this Python code is not too complex, I will try to customize it later. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: fail to post-commit with --revision-range
Can anyone help on this issue? post-commit review is really important for my company. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
fail to post-commit with --revision-range
Hi All,
I am new to here, and I begin to use the reviewboard one weeks ago.
In my company, when we want to make a new release, we MUST review all
changes from this release tag to the last release tag.
]$ post-review --revision-range=v1000:v1001
Error uploading diff: One or more fields had errors (105)
Your review request still exists, but the diff is not attached.
$ post-review --revision-range=v1000:v1001 --debug
>>> Repository info 'Path: 172.21.1.234:12121/home/cvsadmin/sbu-i, Base path: No
ne, Supports changesets: False'
>>> cvs diff -uN -r v1000-r v1001
>>> Looking for '172.21.5.234 /' cookie in /home/xxx/.post-review-cookies.txt
>>> Loaded valid cookie -- no login required
>>> Attempting to create review request for None
>>> HTTP POSTing to http://172.21.5.234/api/json/reviewrequests/new/: {'reposito
ry_path': '172.21.1.234:12121/home/cvsadmin/sbu-i'}
>>> Review request created
>>> Uploading diff, size: 42
>>> HTTP POSTing to http://172.21.5.234/api/json/reviewrequests/21/diff/new/: {}
Error uploading diff: One or more fields had errors (105)
>>> {'fields': {'path': ['The diff file is empty']}, 'stat': 'fail', 'err': {'ms
g': 'One or more fields had errors', 'code': 105}}
Your review request still exists, but the diff is not attached.
There is one obvious error from this debug message.
cvs diff -uN -r v1000-r v1001
I think it should be "cvs diff -uN -r v1000 -r v1001", one space is
missed.
I am not sure if other errors still exist since I do not play python
before.
Can anyone suggest how to fix this issue?
Any suggestions and clue will be much appreciated.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
