Re: Using Review Board for HTML reviews

[Christian Hammond]

Hi Jonathan,

We don’t currently have support for reviewing rendered HTML, at least not
in any ideal way. This is mostly because of the security issues involved
with hosting user-provided HTML content.

We do offer the ability to download the file, view it locally in your
browser, and write a file-level comment, but that’s not the best experience.

Trick with HTML is that you often still need the CSS and images at a
minimum, and possibly some JavaScript with it.

If you don’t mind printing to PDF, you can use Power Pack’s PDF review
capabilities to render it (https://www.reviewboard.org/powerpack/), which
might be a viable option. That would provide the experience I think you’d
want, though with the print-to-PDF step.

Christian


On Fri, Jan 14, 2022 at 13:15 Jonathan Winer  wrote:

> We're evaluating code review tools and trying to determine if we use a
> documentation tool such as madcap flare which produces HTML output, can we
> view the rendered HTML within your code review tool?  Trying to find a way
> to review the rendered output so that it is reader friendly vs the markup
> since this would be used for the documentation team, not the development
> team.
>
> Thanks.
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "Review Board Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/reviewboard/9cd95090-5c5c-43ff-b39d-752c86530ca5n%40googlegroups.com
> 
> .
>
-- 
-- 
Christian Hammond
President/CEO of Beanbag
Makers of Review Board

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/CAE7VndkQ%3DZc7vQQTQUJueMqUzzGKpiOW2rv20g%2BSXT6zGJrOuA%40mail.gmail.com.

Using Review Board for HTML reviews

[Jonathan Winer]

We're evaluating code review tools and trying to determine if we use a 
documentation tool such as madcap flare which produces HTML output, can we 
view the rendered HTML within your code review tool?  Trying to find a way 
to review the rendered output so that it is reader friendly vs the markup 
since this would be used for the documentation team, not the development 
team.

Thanks.

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/9cd95090-5c5c-43ff-b39d-752c86530ca5n%40googlegroups.com.

Re: Commit pre commit review using review board directly

[Christian Hammond]

Hi,

You can use a pre-commit hook for the Subversion repository to enforce
changes to be reviewed before they're allowed in. There's no official one
yet, but we're planning to ship some new hooks as part of the next release
of RBTools.

Basically, you'd write a pre-commit hook that grabs the review request ID
from a commit message, looks up the review request from the API, and checks
the "approved" field for the review request. If it's approved, let it in.
Otherwise, block the commit and display the failure from the
"approval_failure" field.

Planning to make hooks a lot easier to set up and configure in RBTools
0.7.10.

Christian

-- 
Christian Hammond
President/CEO of Beanbag 
Makers of Review Board 

On Mon, Feb 13, 2017 at 9:53 AM, Dhruv Paranjape 
wrote:

> So I am setting up review board for myself and my team. We work with a
> self hosted svn repository. Earlier I have worked with gerrit and git. I
> loved how gerrit allowed control over the repository and all commits had to
> be reviewed, but yet so easy to merge. Was wondering if you guys could help
> me setup something similar with review board + svn.
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Commit pre commit review using review board directly

[Dhruv Paranjape]

So I am setting up review board for myself and my team. We work with a self 
hosted svn repository. Earlier I have worked with gerrit and git. I loved how 
gerrit allowed control over the repository and all commits had to be reviewed, 
but yet so easy to merge. Was wondering if you guys could help me setup 
something similar with review board + svn.

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Using review board post checkin

[manish agarwal]

hi
I am working in a small team of 4 people where every one is checking in 
code and its happening at a fast pace . We want an open source tool which 
generates review requests when ever some one does a perforce checkin and 
emails it to all the people . Can I run tool  review board on a standalone 
machine which can email to all users After a checkin is done . if yes can 
you point me to resources where i can find steps to do so easily ?

regards
manish 

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 3885 in reviewboard: Not able to publish the changes using review board

[reviewboard]

Updates:
Status: Incomplete

Comment #3 on issue 3885 by trowb...@gmail.com: Not able to publish the  
changes using review board

https://code.google.com/p/reviewboard/issues/detail?id=3885

(No comment was entered for this change.)

--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at http://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/d/optout.

Issue 3885 in reviewboard: Not able to publish the changes using review board

[reviewboard]

Status: New
Owner: 
Labels: Type-Defect Priority-Medium

New issue 3885 by sodanish...@gmail.com: Not able to publish the changes  
using review board

https://code.google.com/p/reviewboard/issues/detail?id=3885

*** READ THIS BEFORE POSTING!
***
*** You must complete this form in its entirety, or your bug report will be
*** rejected.
***
*** If you have a security issue to report, please send it confidentially
to
*** secur...@reviewboard.org. Posting security-related issues to this bug
*** tracker causes us to have to do an emergency release.
***
*** For customer support, please post to reviewbo...@googlegroups.com
***
*** If you have a patch, please submit it to
http://reviews.reviewboard.org/
***
*** This bug tracker is public. Please check that any logs or other
information
*** that you include has been stripped of confidential information.


What version are you running?


What's the URL of the page containing the problem?


What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What operating system are you using? What browser?


Please provide any additional information below.


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at http://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 3885 in reviewboard: Not able to publish the changes using review board

[reviewboard]

Comment #1 on issue 3885 by sodanish...@gmail.com: Not able to publish the  
changes using review board

https://code.google.com/p/reviewboard/issues/detail?id=3885

What version are you running?
 Review Board 1.7.7.1





What's the URL of the page containing the problem

https://reviewboard.netapp.com/r/310171/diff/#index_header


What steps will reproduce the problem?
1. using above link, click on publish review button it failed.
2.
3.

What is the expected output? What do you see instead?
It should publish the changes and should get automated mail

What operating system are you using? What browser?
firefox

Please provide any additional information below.

--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at http://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 3885 in reviewboard: Not able to publish the changes using review board

[reviewboard]

Updates:
Status: NeedInfo

Comment #2 on issue 3885 by trowb...@gmail.com: Not able to publish the  
changes using review board

https://code.google.com/p/reviewboard/issues/detail?id=3885

Is this publishing a review or a review request?

Are there any errors in the browser javascript console, or (check with your  
server administrator for this), are there any errors in the server logs?


--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at http://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/d/optout.

Re: Three questions for using Review Board 1.0.6

[J Arrizza]

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 cppge...@gmail.com 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

[J Arrizza]

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 aschwa...@gmail.comwrote:

 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 cppge...@gmail.com wrote:

 On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz aschwa...@gmail.comwrote:

   - 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.comreviewboard%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.comreviewboard%2bunsubscr...@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

[J Arrizza]

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 aschwa...@gmail.comwrote:

 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 aschwa...@gmail.comwrote:

 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

[Andrew Schwartz]

On Thu, Oct 28, 2010 at 12:28 PM, J Arrizza cppge...@gmail.com 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 aschwa...@gmail.comwrote:

 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 aschwa...@gmail.comwrote:

 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.comreviewboard%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 

Re: Three questions for using Review Board 1.0.6

[J Arrizza]

On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz aschwa...@gmail.comwrote:

   - 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

[Andrew Schwartz]

N

On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe
eduardofelip...@gmail.comwrote:

 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 

Re: Three questions for using Review Board 1.0.6

[Eduardo Felipe]

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. 

Re: Three questions for using Review Board 1.0.6

[Andrew]

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.cnwrote:

   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.comreviewboard%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 

Re: Three questions for using Review Board 1.0.6

[Christian Hammond]

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.cnwrote:
 
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.comreviewboard%2bunsubscr...@googlegroups.com
 reviewboard%2bunsubscr...@googlegroups.comreviewboard%252bunsubscr...@googlegroups.com
 

Re: Issue 775 in reviewboard: Issues when using Review Board with the It's All Text Firefox Extension

[reviewboard]

Comment #11 on issue 775 by jrodman: Issues when using Review Board with  
the It's All Text Firefox Extension

http://code.google.com/p/reviewboard/issues/detail?id=775

OK, we're just megastale then.  Sorry to pollute the bug.

--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To post to this group, send email to reviewboard-iss...@googlegroups.com.
To unsubscribe from this group, send email to 
reviewboard-issues+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/reviewboard-issues?hl=en.

Re: Issue 775 in reviewboard: Issues when using Review Board with the It's All Text Firefox Extension

[reviewboard]

Comment #9 on issue 775 by jrodman: Issues when using Review Board with  
the It's All Text Firefox Extension

http://code.google.com/p/reviewboard/issues/detail?id=775

Having this problem with It's All Text 1.3.1.
Perhaps our Reviewboard version is stale? I am not seeing any way to derive  
the reviewboard installation version from the UI.


--
You received this message because you are subscribed to the Google Groups 
reviewboard-issues group.
To post to this group, send email to reviewboard-iss...@googlegroups.com.
To unsubscribe from this group, send email to 
reviewboard-issues+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/reviewboard-issues?hl=en.

Re: Three questions for using Review Board 1.0.6

[Christian Hammond]

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 james_tong...@yahoo.com.cnwrote:

 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.comreviewboard%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

Three questions for using Review Board 1.0.6

[james tong]

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

Re: Using Review Board

[Raghu]

As Christian pointed out, this is more of a process issue.

At my work, we have a similar process. Every developer work on a
branch and checks in code to the branch. At some suitable time the
code is integrated to the mainline. Checkins to the trunk needs
permissions through perforce ACLs.

-Raghu

On May 12, 12:48 am, Christian Hammond chip...@chipx86.com wrote:
 Hi Chris,

 Review Board doesn't have any way of preventing code from being checked in.
 As H M said, you'll need a pre-commit hook for this. I think there's one 
 onhttp://reviews.review-boardorg/somewhere. At some point we may bundle and
 document one, but not until we have a solid concept of policy control in the
 project, and we don't have that today.

 Updating diffs is a manual process, but post-review makes it a lot easier.
 Just one command and your review request is created/updated. Some people
 automate this with a post-commit hook as well, but again, we don't have an
 official one to recommend at this time.

 Christian

 --
 Christian Hammond - chip...@chipx86.com
 Review Board -http://www.review-board.org
 VMware, Inc. -http://www.vmware.com

 On Mon, May 11, 2009 at 8:03 AM, Chris c.d.whitco...@gmail.com wrote:

  This discussion was moved from another one that was about windows
  installs.

  I was hoping to use review board as such:

  The main development trunk is stable.
  We want to add something new, so a developer takes a branch to work in
  leaving trunk alone.
  Once the developer is happy with their work then add a review request
  (this may pass first time or need a few iterations)
  Once the code gets the ok the developer moves the code from the branch
  into trunk.

  My main concerns are the process of adding the diffs is quite manual,
  can it be automated?

  Also unless code has been given the OK i dont want it to get into
  trunk, is this possible? i.e. can we stop people committing to trunk,
  or is that more something we need to deal with at a people level not
  an automation level?

  Cheers,

  Chris
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Using Review Board

[Chris]

This discussion was moved from another one that was about windows
installs.

I was hoping to use review board as such:

The main development trunk is stable.
We want to add something new, so a developer takes a branch to work in
leaving trunk alone.
Once the developer is happy with their work then add a review request
(this may pass first time or need a few iterations)
Once the code gets the ok the developer moves the code from the branch
into trunk.

My main concerns are the process of adding the diffs is quite manual,
can it be automated?

Also unless code has been given the OK i dont want it to get into
trunk, is this possible? i.e. can we stop people committing to trunk,
or is that more something we need to deal with at a people level not
an automation level?

Cheers,

Chris
--~--~-~--~~~---~--~~
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: Using Review Board

[H M]

Chris wrote:
 Also unless code has been given the OK i dont want it to get into
 trunk, is this possible? i.e. can we stop people committing to trunk,
 or is that more something we need to deal with at a people level not
 an automation level
I don't think this is done out of the box. At least not with the version 
of RB that we have (which is quite old).

We have implemented this with a pre-commit hook in Subversion. The hook 
checks the review using the API, and if 1 or more Ship It comments 
exist, then it considers it OK for committing.

If the author of the review request and the person posting a Ship It 
comment is the same, then we have a configurable way of dealing with 
these cases. Currently, we still allow the changes to be committed but 
we send out a policy violation email to those concerned. The reasoning 
is that if someone decides to Self-review the code, then this must be 
either something urgent OK'd by management.

Hovanes M.


--~--~-~--~~~---~--~~
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: Using Review Board

[Christian Hammond]

Hi Chris,

Review Board doesn't have any way of preventing code from being checked in.
As H M said, you'll need a pre-commit hook for this. I think there's one on
http://reviews.review-boardorg/ somewhere. At some point we may bundle and
document one, but not until we have a solid concept of policy control in the
project, and we don't have that today.

Updating diffs is a manual process, but post-review makes it a lot easier.
Just one command and your review request is created/updated. Some people
automate this with a post-commit hook as well, but again, we don't have an
official one to recommend at this time.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Mon, May 11, 2009 at 8:03 AM, Chris c.d.whitco...@gmail.com wrote:


 This discussion was moved from another one that was about windows
 installs.

 I was hoping to use review board as such:

 The main development trunk is stable.
 We want to add something new, so a developer takes a branch to work in
 leaving trunk alone.
 Once the developer is happy with their work then add a review request
 (this may pass first time or need a few iterations)
 Once the code gets the ok the developer moves the code from the branch
 into trunk.

 My main concerns are the process of adding the diffs is quite manual,
 can it be automated?

 Also unless code has been given the OK i dont want it to get into
 trunk, is this possible? i.e. can we stop people committing to trunk,
 or is that more something we need to deal with at a people level not
 an automation level?

 Cheers,

 Chris
 


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---