Christian, Sorry for letting this thread slide for so long.
I'm talking about a review request being for a series of changesets. In our case, we often will split a single feature change into small, easily reviewed changesets. It would be nice to be able to put all of these changesets into a single review request. Does that make sense? On Sun, Aug 1, 2010 at 3:49 PM, Christian Hammond <chip...@chipx86.com>wrote: > I'm not sure I fully understand the functionality you're asking for, > Andrew. Are we just talking about creating new diffs to replace the old > ones? Isn't that what we have today? Are you asking for that + branch > tracking? > > > Christian > > -- > Christian Hammond - chip...@chipx86.com > Review Board - http://www.reviewboard.org > VMware, Inc. - http://www.vmware.com > > > On Thu, Jul 29, 2010 at 8:07 PM, Eduardo Felipe <eduardofelip...@gmail.com > > wrote: > >> Andrew, >> >> I'm afraid that won't be possible with the code I'm writing. I'm >> basing this on a post-commit style of review. In this scenario, you >> would write a new commit E that fixes the issues mentioned on the >> review, instead of rewriting the patches. >> >> The model you are suggesting is harder to do on something other than >> git, e.g. mercurial, unless you use mqueues to do it. >> >> I could even write the code, but I don't think I'll be able to do it >> in time for the end of the Summer of Code Program. >> >> Christian, would you like to comment on this issue? >> >> Cheers, >> >> Eduardo. >> >> On Thu, Jul 29, 2010 at 1:55 PM, Andrew Schwartz <aschwa...@gmail.com> >> wrote: >> > N >> > >> > On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe < >> eduardofelip...@gmail.com> >> > wrote: >> >> >> >> Sure! >> >> >> >> I am working on making the support for DVCS better by implementing the >> >> following: >> >> >> >> Remote branch tracking: >> >> >> >> Based on the notion of feature branches one could build around the >> >> notion of long lived reviews that could be updated as the code is >> >> updated, all in the Web UI, without having to post another review and >> >> lose the context information. As such reviews could be used to >> >> document coding decisions before a branch is integrated in the main >> >> line, and could be automatically closed once the branch is merged >> >> back. My implementation focus mainly on Git for the time being, but it >> >> will also support Mercurial before it's ready to go. >> >> >> >> Remodeling diff versioning: >> >> >> >> Currently when a new review is created on Review Board, it takes the >> >> uploaded patch, infer the oldest committed version referenced by the >> >> patch and applies the patch on top of it, creating a new version. It >> >> then goes ahead and mark that patch as version one. If the user >> >> uploads a new patch, version two is created, and with that the >> >> possibility of seeing just what changed between the two versions, >> >> therefore reviewing the part, not the whole. >> >> >> >> With the new workflow upon submitting a patch to be reviewed, instead >> >> of just loading the submitted patch and marking it as version one, >> >> Review Board would fetch the diff for every incremental revision from >> >> the oldest version present in the diff to the newest, apply it on top >> >> of the head and mark that as a version of the patch, in practice >> >> creating a version containing all changes from the base up to that >> >> point. It would also store information about which commits formed that >> >> partial patch to display later. >> >> >> >> If the repository that holds the commits is not accessible to >> >> ReviewBoard then in order to take advantage of this feature you'll >> >> have to use post-review from the command line, so it can create a >> >> bundle containing all the information necessary for this view. >> >> >> > >> > Sounds promising. If a review response involves creating a new set of >> > changesets to replace the old set of changesets, will there by a concept >> of >> > sub-versions? For instance: >> > >> > Say A is the head of the current master repository. I'm submitting >> three >> > related changesets for review, B, C and D. Then, as a result of the >> review, >> > I now want to update the diffs with B', C' and D'. Will there be any >> > mechanism for doing this and easily seeing that B' is related to B, >> etc.? >> > >> >> >> >> I expect this code to be done by the second week of August (that's >> >> when the Summer of Code ends), and to be integrated on a new version >> >> when Christian agrees with everything I've done, hehehe. >> >> >> >> Cheers, >> >> >> >> Eduardo. >> >> >> >> On Tue, Jul 27, 2010 at 4:37 PM, Christian Hammond < >> chip...@chipx86.com> >> >> wrote: >> >> > Eduardo, can you give a summary of what you're working on? >> >> > >> >> > Christian >> >> > >> >> > -- >> >> > Christian Hammond - chip...@chipx86.com >> >> > Review Board - http://www.reviewboard.org >> >> > VMware, Inc. - http://www.vmware.com >> >> > >> >> > >> >> > On Tue, Jul 27, 2010 at 12:33 PM, Andrew <aschwa...@gmail.com> >> wrote: >> >> >> >> >> >> Hi all. Please let me know what's going on with DVCS and Review >> >> >> Board. I know that there are ways to make it work (as we are in my >> >> >> organization), but it would be nice for it to be better integrated >> in >> >> >> the project with reviewing multiple changesets, etc. Thanks. >> >> >> >> >> >> On Jul 20, 5:40 pm, Andrew <aschwa...@gmail.com> wrote: >> >> >> > I'm wondering if there has been any progress on theDVCSfront. I'd >> >> >> > be very interested in the current design. Is one of the GSOC >> >> >> > students >> >> >> > actively working on this? >> >> >> > >> >> >> > On Jun 2, 6:08 pm, Christian Hammond <chip...@chipx86.com> wrote: >> >> >> > >> >> >> > > Hi James, >> >> >> > >> >> >> > > Today, each logical change is meant to have its own review >> request. >> >> >> > > If >> >> >> > > you >> >> >> > > have three things that are related but are separately worked on, >> >> >> > > each >> >> >> > > should >> >> >> > > be put up for review separately. There's no notion of a review >> >> >> > > request >> >> >> > > that >> >> >> > > encompasses several different changes. I personally think this >> is >> >> >> > > good, as >> >> >> > > it keeps it organized and keeps things smaller. >> >> >> > >> >> >> > > Where things may change over the next several months is how >> diffs >> >> >> > > are >> >> >> > > handled when used with aDVCSlike Git. In those cases, it makes >> >> >> > > sense >> >> >> > > to be >> >> >> > > able to have a review request for one change but with several >> >> >> > > iterative >> >> >> > > diffs leading up to that one change. It would still be one >> logical >> >> >> > > change, >> >> >> > > but with multiple diffs instead of one big diff. I don't know >> how >> >> >> > > well >> >> >> > > this >> >> >> > > concept would really apply in the SVN guess. I suspect it >> wouldn't. >> >> >> > >> >> >> > > Now, I'm not fully sure I understand how your project is >> organized. >> >> >> > > Is >> >> >> > > each >> >> >> > > Java component in a different repository? If not, can't one diff >> be >> >> >> > > generated that has all the changes to all the components, and >> then >> >> >> > > put >> >> >> > > that >> >> >> > > up as one review request? >> >> >> > >> >> >> > > If they are indeed in different repositories, then what you'd >> need >> >> >> > > is >> >> >> > > a way >> >> >> > > to have one review request that spans repositories. This is >> >> >> > > something >> >> >> > > that, >> >> >> > > for many reasons, we wouldn't be doing, so you'd have to have >> one >> >> >> > > review >> >> >> > > request per repository. >> >> >> > >> >> >> > > I don't really understand your second request. It sounds like >> >> >> > > something that >> >> >> > > could be solved by aDVCSsolution, or multiple checkouts of your >> >> >> > > repository. >> >> >> > >> >> >> > > For the third request, this is something that's not really on >> the >> >> >> > > radar for >> >> >> > > a release right now. In order to do it right, I think we need to >> do >> >> >> > > more >> >> >> > > than revision ranges (especially forDVCSsystems where it's not >> >> >> > > actually a >> >> >> > > numeric range). I'd like to do it correctly if we do it, and >> that >> >> >> > > will >> >> >> > > take >> >> >> > > some time and planning. >> >> >> > >> >> >> > > Christian >> >> >> > >> >> >> > > -- >> >> >> > > Christian Hammond - chip...@chipx86.com >> >> >> > > Review Board -http://www.reviewboard.org >> >> >> > > VMware, Inc. -http://www.vmware.com >> >> >> > >> >> >> > > On Thu, May 20, 2010 at 12:41 AM, james tong >> >> >> > > <james_tong...@yahoo.com.cn>wrote: >> >> >> > >> >> >> > > > Hi, all, >> >> >> > > > My team now is using the ReviewBoard-1.0.6 which is running on >> >> >> > > > the >> >> >> > > > Cent-OS >> >> >> > > > server. And this is really fantastic software which help us a >> lot >> >> >> > > > for code >> >> >> > > > review. >> >> >> > > > However, we also found some troubles when doing review. >> >> >> > >> >> >> > > > First, In our project, we need to update the code in more than >> >> >> > > > one >> >> >> > > > components (java project), so we may generate several diff >> files >> >> >> > > > for >> >> >> > > > one >> >> >> > > > main function. And we find that it is impossible (or it is >> >> >> > > > possible >> >> >> > > > but we >> >> >> > > > did not find that?) to upload these diff files in the same >> review >> >> >> > > > request. >> >> >> > > > Then we have to create several review requests for the same >> main >> >> >> > > > function. >> >> >> > > > So, I send this email and hope to know what is others' way for >> >> >> > > > this >> >> >> > > > problem? >> >> >> > > > I think this may be a common case. >> >> >> > >> >> >> > > > Second, for some case, we may need to change the same class >> for >> >> >> > > > two >> >> >> > > > main >> >> >> > > > functions at the same period (during the week by different >> team >> >> >> > > > members), so >> >> >> > > > how to generate diff file and create the review request for >> this >> >> >> > > > case? (Our >> >> >> > > > review request is created base on main function changes, and >> for >> >> >> > > > this case, >> >> >> > > > one review request will contain the changes for other main >> >> >> > > > function, >> >> >> > > > there >> >> >> > > > may be some confusing). I know this might not be in the scope >> of >> >> >> > > > this mail >> >> >> > > > list, but still hope to get some useful suggestion. >> >> >> > >> >> >> > > > Third, we are using svn as the repository. And we want to >> know >> >> >> > > > that >> >> >> > > > when >> >> >> > > > we can simply input the revision numbers in the web GUI for >> >> >> > > > creating >> >> >> > > > a >> >> >> > > > review request without uploading the diff file. :-) >> >> >> > >> >> >> > > > Many Thanks >> >> >> > > > BR// >> >> >> > >> >> >> > > > -------------- >> >> >> > > > Best Regards! >> >> >> > > > James.Tong >> >> >> > > > 童熙 >> >> >> > >> >> >> > > > -- >> >> >> > > > Want to help the Review Board project? Donate today at >> >> >> > > >http://www.reviewboard.org/donate/ >> >> >> > > > Happy user? Let us know athttp://www.reviewboard.org/users/ >> >> >> > > > -~----------~----~----~----~------~----~------~--~--- >> >> >> > > > To unsubscribe from this group, send email to >> >> >> > > > >> >> >> > > > >> >> >> > > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com> >> <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com> >> > >> >> >> > > > For more options, visit this group at >> >> >> > > >http://groups.google.com/group/reviewboard?hl=en >> >> >> >> >> >> -- >> >> >> 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<reviewboard%2bunsubscr...@googlegroups.com> >> >> >> For more options, visit this group at >> >> >> http://groups.google.com/group/reviewboard?hl=en >> >> > >> > >> > >> > > -- 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
