Re: Three questions for using Review Board 1.0.6
It looks like --parent works. Not sure what I did before, but when I reran a test based on a series of changes to a single test file, the diffs come out as expected. I didn't try file deletions/additions just changes within a single file: - Created a file with three lines line1 line2 line3 - commited and pushed it (say mercurial revision 93) - changed line2 to line2A - commited and pushed it; (say hg revision 94) - changed line3 to line3B - commited and pushed it; (say hg revision 96) - added a new line4 - commited and pushed it; (say hg revision 98) - created a code review: hg postreview 93 (start at the oldest revision first) (creates code review id 50) - added the other revisions hg postreview -e 50 --parent 93 94 hg postreview -e 50 --parent 93 96 hg postreview -e 50 --parent 93 98 - checked out the diffs in RB and the left hand side for all revisions is the file at hg revision 93. The right hand side for the revisions matches up for 94, 96 and 98 as expected. Very nice! The command line is kind of clunky, kind of calls out for a GUI version doesn't it?! We're going to try it as part of our process for a while to see if there's any hidden glitches in more realistic use cases but definitely promising. Thanks for your help, John On Mon, Nov 1, 2010 at 11:30 PM, J Arrizza wrote: > 1. interesting. I tried "parent" but it didn't seem to work the way I > expected. It should compare the current revision with the parent revision, > but didn't seem to do that. I suspect I probably did not set up the test > correctly. In any case, I'll give it another try. > > -- 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: Three questions for using Review Board 1.0.6
1. interesting. I tried "parent" but it didn't seem to work the way I expected. It should compare the current revision with the parent revision, but didn't seem to do that. I suspect I probably did not set up the test correctly. In any case, I'll give it another try. On Sat, Oct 30, 2010 at 11:01 AM, Andrew Schwartz wrote: > If I'm understanding you correctly, you're saying two things: > 1. As a new changeset is created by the developer, the developer will > update the review request to be based at the same original revision but with > the set of changesets under review including all of the original changesets > under review + the new changeset. This is already doable in the postreview > Mercurial extension with the "parent" argument. > > 2. You want comments to be translated over to the new revision. I don't > know that this is currently doable in ReviewBoard. Chris, am I missing > something? > > On Thu, Oct 28, 2010 at 10:59 PM, J Arrizza wrote: > >> On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz wrote: >> >>> - have a "rollup" mechanism. As the additional revisions are added, the >>> changes are rolled up into one aggregate diff. (I assume this would be very >>> complicated code and so might not be doable without significant risk) >>> >>> What do you mean? >>> >>> >> Say there are 2 diffs/revisions in the CR. The diff is then between v1 and >> v2. Comments are applied to lines in v2. So far so good. >> >> A new version v3 is added to the CR. The diff is then "rolled forward" so >> it now shows the diffs between v1 and v3. The comments applied to lines in >> v2 are moved to the correct lines in the version 3 text. (And there is no >> more "v2" anymore, there's one and only one diff). >> >> A new version v4 is added to the CR and the diff is rolled forward again >> to show the difference between v1 and v4; comments in v2 and v3 rolled >> forward too; v3 is removed. >> >> And so on... >> >> Another way to look at it is it's a "left-anchored diff". The left-hand >> side of the diff never changes, only the right hand side does. >> >> Like I said, the algorithm likely has many edge conditions and exceptions >> and so is likely to be very complicated code. >> >> >> John >> >> >> >> >> -- >> 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 >> > > -- > 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 > -- John blog: http://arrizza.blogspot.com/ web: http://www.arrizza.com/ -- 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: Three questions for using Review Board 1.0.6
If I'm understanding you correctly, you're saying two things: 1. As a new changeset is created by the developer, the developer will update the review request to be based at the same original revision but with the set of changesets under review including all of the original changesets under review + the new changeset. This is already doable in the postreview Mercurial extension with the "parent" argument. 2. You want comments to be translated over to the new revision. I don't know that this is currently doable in ReviewBoard. Chris, am I missing something? On Thu, Oct 28, 2010 at 10:59 PM, J Arrizza wrote: > On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz wrote: > >> - have a "rollup" mechanism. As the additional revisions are added, the >> changes are rolled up into one aggregate diff. (I assume this would be very >> complicated code and so might not be doable without significant risk) >> >> What do you mean? >> >> >>> >>> > Say there are 2 diffs/revisions in the CR. The diff is then between v1 and > v2. Comments are applied to lines in v2. So far so good. > > A new version v3 is added to the CR. The diff is then "rolled forward" so > it now shows the diffs between v1 and v3. The comments applied to lines in > v2 are moved to the correct lines in the version 3 text. (And there is no > more "v2" anymore, there's one and only one diff). > > A new version v4 is added to the CR and the diff is rolled forward again to > show the difference between v1 and v4; comments in v2 and v3 rolled forward > too; v3 is removed. > > And so on... > > Another way to look at it is it's a "left-anchored diff". The left-hand > side of the diff never changes, only the right hand side does. > > Like I said, the algorithm likely has many edge conditions and exceptions > and so is likely to be very complicated code. > > > John > > > > > -- > 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 > -- 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: Three questions for using Review Board 1.0.6
On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz wrote: > - have a "rollup" mechanism. As the additional revisions are added, the > changes are rolled up into one aggregate diff. (I assume this would be very > complicated code and so might not be doable without significant risk) > > What do you mean? > > >> >> Say there are 2 diffs/revisions in the CR. The diff is then between v1 and v2. Comments are applied to lines in v2. So far so good. A new version v3 is added to the CR. The diff is then "rolled forward" so it now shows the diffs between v1 and v3. The comments applied to lines in v2 are moved to the correct lines in the version 3 text. (And there is no more "v2" anymore, there's one and only one diff). A new version v4 is added to the CR and the diff is rolled forward again to show the difference between v1 and v4; comments in v2 and v3 rolled forward too; v3 is removed. And so on... Another way to look at it is it's a "left-anchored diff". The left-hand side of the diff never changes, only the right hand side does. Like I said, the algorithm likely has many edge conditions and exceptions and so is likely to be very complicated code. John -- 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: Three questions for using Review Board 1.0.6
On Thu, Oct 28, 2010 at 12:28 PM, J Arrizza wrote:
> Andrew,
>
> I am still new to RB, and we are looking for something similar as well. We
> have an SCR in our defect tracking system that aggregates all work for
> change. Developers create a series of changesets and then tag each of those
> with the SCR. When it's time to do a code review, we'd like to have one code
> review for the entire SCR. So if I'm not mistaken, we are looking for the
> same thing you are ("review request being for a series of changesets").
>
> Here are my thoughts (FWIW) on this:
>
> There needs to be a way add multiple changeset ids or revision numbers or
> whatever on the command line. Currently we handle it through a manual
> process:
>
>use "hg log" to a list of changesets
>make a list of the changeset revision ids for the SCR, say (88, 89
> and 93)
>starting with the oldest revision (88), create the review using "hg
> postreview 88" (the mercurial-postreview allows this, don't know if the
> others do)
>say the new review is id 33
>add the remaining revisions one by one from oldest to newest:
> postreview -e 33 89
> postreview -e 33 93
>
>when you go into RB GUI, the three changesets show up as three
> revisions 1, 2, and 3 where 1->revision88, 2->revision89 and 3->revision93.
>
> Cons:
>- manual steps are error prone
>- if you screw up and add a revision you shouldn't have, not possible to
> remove that from the review
>- if you screw up and forget to add a revision, not possible to insert
> that into the existing review
>- the multiple revisions in the code review are confusing to the
> reviewers.
>- During a review, it's not possible to tell if a problem in the code in
> revision x is actually fixed later on in revision y.
>
Also, as far as I can tell, the "spirit" of multiple revisions in
ReviewBoard is that each changeset replaces the previous changeset and may
be a response to a previous changeset. It would be nice to be able to post
5 changesets that are logically one review request, have them get reviewed,
then post 5 new changesets that replace the original 5 changesets and
address issues found in review. The GUI would allow the user to diff
between the original changeset 2 and the new changeset 2, for instance.
>
> So, in short, the extensions I'd like to see are:
>
> - the manual part of the review request automated. Perhaps it's as simple
> as allowing multiple changesets to be put on the command line. Or it may
> have to get more complicated (e.g. list the revisions for the developer
> through some gui and allow them to select the ones they want from that list)
>
We use "hg postreview" as well. I'm fairly certain that the automation
you're mentioning would be straightforward to implement, as the codebase for
the postreview plugin to mercurial is relatively small and self-contained.
You could suggest it to Gilles Moris at code.google.com/p/*mercurial*-*
reviewboard*/ or to mdelagra at
http://bitbucket.org/mdelagra/mercurial-reviewboard/ to see if either of
them would be interested in the feature.
We are currently only using reviewboard for single-changeset review
requests, so we don't have a high need for this feature.
> - have a "rollup" mechanism. As the additional revisions are added, the
> changes are rolled up into one aggregate diff. (I assume this would be very
> complicated code and so might not be doable without significant risk)
>
What do you mean?
>
> I'm not sure if there are other options available...
>
> John
>
>
>
>
> On Tue, Oct 26, 2010 at 7:25 PM, Andrew Schwartz wrote:
>
>> I think that what I'm talking about is the same thing that Eduardo called
>> "Remodelling diff versioning". Does that seem right to you?
>>
>>
>>
>>
>> On Tue, Oct 26, 2010 at 7:17 PM, Andrew Schwartz wrote:
>>
>>> 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?
>>>
>>>
>>>
>>> --
> 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
>
--
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,
Re: Three questions for using Review Board 1.0.6
Andrew,
I am still new to RB, and we are looking for something similar as well. We
have an SCR in our defect tracking system that aggregates all work for
change. Developers create a series of changesets and then tag each of those
with the SCR. When it's time to do a code review, we'd like to have one code
review for the entire SCR. So if I'm not mistaken, we are looking for the
same thing you are ("review request being for a series of changesets").
Here are my thoughts (FWIW) on this:
There needs to be a way add multiple changeset ids or revision numbers or
whatever on the command line. Currently we handle it through a manual
process:
use "hg log" to a list of changesets
make a list of the changeset revision ids for the SCR, say (88, 89
and 93)
starting with the oldest revision (88), create the review using "hg
postreview 88" (the mercurial-postreview allows this, don't know if the
others do)
say the new review is id 33
add the remaining revisions one by one from oldest to newest:
postreview -e 33 89
postreview -e 33 93
when you go into RB GUI, the three changesets show up as three
revisions 1, 2, and 3 where 1->revision88, 2->revision89 and 3->revision93.
Cons:
- manual steps are error prone
- if you screw up and add a revision you shouldn't have, not possible to
remove that from the review
- if you screw up and forget to add a revision, not possible to insert
that into the existing review
- the multiple revisions in the code review are confusing to the
reviewers.
- During a review, it's not possible to tell if a problem in the code in
revision x is actually fixed later on in revision y.
So, in short, the extensions I'd like to see are:
- the manual part of the review request automated. Perhaps it's as simple
as allowing multiple changesets to be put on the command line. Or it may
have to get more complicated (e.g. list the revisions for the developer
through some gui and allow them to select the ones they want from that list)
- have a "rollup" mechanism. As the additional revisions are added, the
changes are rolled up into one aggregate diff. (I assume this would be very
complicated code and so might not be doable without significant risk)
I'm not sure if there are other options available...
John
On Tue, Oct 26, 2010 at 7:25 PM, Andrew Schwartz wrote:
> I think that what I'm talking about is the same thing that Eduardo called
> "Remodelling diff versioning". Does that seem right to you?
>
>
>
>
> On Tue, Oct 26, 2010 at 7:17 PM, Andrew Schwartz wrote:
>
>> 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?
>>
>>
>>
>>
--
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: Three questions for using Review Board 1.0.6
I think that what I'm talking about is the same thing that Eduardo called "Remodelling diff versioning". Does that seem right to you? On Tue, Oct 26, 2010 at 7:17 PM, Andrew Schwartz wrote: > 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 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 >>> 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> >>>
Re: Three questions for using Review Board 1.0.6
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 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 > 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 >> 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 >> wrote: >> >> >> >> >>
Re: Three questions for using Review Board 1.0.6
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 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 > 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 > > >> 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 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 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? > >> >> > > >> >> >
Re: Three questions for using Review Board 1.0.6
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 wrote: > N > > On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe > 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 >> 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 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 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 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 >> >> > > hand
Re: Three questions for using Review Board 1.0.6
N On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe 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 > 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 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 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 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
Re: Three questions for using Review Board 1.0.6
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. 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 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 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 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 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 rang
Re: Three questions for using Review Board 1.0.6
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 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 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 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/ > > > > -~--~~
Re: Three questions for using Review Board 1.0.6
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 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 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 > > 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 > > > 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 review
Re: Three questions for using Review Board 1.0.6
I'm wondering if there has been any progress on the DVCS front. 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 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 a DVCS like 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 a DVCS solution, 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 for DVCS systems 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 > 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 > > 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
Re: Three questions for using Review Board 1.0.6
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 a DVCS like 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 a DVCS solution, 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 for DVCS systems 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 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 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 -- 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
Three questions for using Review Board 1.0.6
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 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
