Are you uploading one diff for each separate change to a review request, or are you uploading diffs containing just the new changes requested for each iteration?
The idea is that one review request maps to one diff. Each diff you upload is just another iteration on that diff, but one that consists of all the changes made to the tree that you're proposing, not just changes made against what you've already uploaded. So if you have two diffs, each fundamentally different and focusing on different things, you should have two review requests. The latest revision of any diff on a review request should contain all the proposed changes for review, not just a small incremental diff. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Thu, Nov 13, 2008 at 12:01 PM, Geoffrey Zheng <[EMAIL PROTECTED]>wrote: > > Sorry if the word "baseline" is confusing--now it seems like it's the > wrong word to use. > > What I mean is that I'd like to see the cumulative effect of all > diffs, because as I mentioned in the example workflow, it's necessary > and important at the end of the iterations to ignore the intermediate > diffs and see a single diff as if all the diffs were committed at > once. > > On Nov 7, 3:03 pm, "Jeff Andros" <[EMAIL PROTECTED]> wrote: > > It sounds like he means the perforce baseline concept... meaning the > > youngest common ancestor node in the revision tree > > Jeff > > O|||||||O > > > > Help me and the Leukemia and Lymphoma society fight blood cancers: > http://pages.teamintraining.org/dm/tucson08/jandros > > > > On Thu, Nov 6, 2008 at 1:17 PM, Christian Hammond <[EMAIL PROTECTED] > >wrote: > > > > > I'm confused as to what the problem is. When you say baseline, you mean > > > what's in the repository? Just use the "Jump to revision" for that. > Clicking > > > "View Diff" will take you to the most recent diff, which compares > against > > > what's in the repository. > > > > > If that's not what you mean, can you explain your definition of > baseline? > > > > > Christian > > > > > -- > > > Christian Hammond - [EMAIL PROTECTED] > > > VMware, Inc. > > > > > On Thu, Nov 6, 2008 at 8:45 AM, Geoffrey <[EMAIL PROTECTED]> > wrote: > > > > >> Hi all. I feel it's pretty essential to compare updated diffs with > > >> baseline, but I can't find any mentioning of it in this group or the > > >> bug tracker. > > > > >> What I mean is this: suppose you have two diffs in a review request. > > >> Right now you'll see this in the diff view: > > > > >> Jump to revision: 1 2 > > >> Changes between r2 and: 1 2 > > > > >> If you click 1 and 2 in the second row, you get the interdiff. > > > > >> But what I want to see is the diff between 2 and 1's baseline. > > > > >> Why? Think of the workflow: > > >> 1) Developer posted diff 1 to be reviewed. > > >> 2) Reviewer noticed a problem. > > >> 3) Developer posted diff 2 to address it. > > >> 4) Reviewer is ok with the second change, but now s/he wants to see > > >> the combined effect: how will baseline change once all the changes are > > >> committed? > > > > >> This is more obvious when you have many iterations. In the end you > > >> don't care about the interdiffs any more because you have already > > >> worked through them. You want to check the total diff between baseline > > >> and last revision for a final review. > > > > >> I think it makes sense to change the diff view to only one line: > > > > >> Changes between: 0 1 2 > > > > >> It's more intuitive than the current two-line view, and you can > > >> compare arbitrary versions. > > > > >> If this makes sense, how difficult is it to implement? > > > > >> Thanks a lot! > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
