Review Board Ticket #4923: webhooks send duplicate Content-Length headers under python3
-- To reply, visit https://hellosplat.com/s/beanbag/tickets/4923/ -- New ticket #4923 by nuxi For Beanbag, Inc. > Review Board Status: New Tags: Priority:Medium, Type:Defect -- webhooks send duplicate Content-Length headers under python3 == # What version are you running? 4.0 RC2 (on Python 3.8) I believe its running from the official docker images. # What's the URL of the page containing the problem? Not entirely sure what to put here since its not really a page, I guess: `/admin/db/notifications/webhooktarget/` # What steps will reproduce the problem? 1. Run under python3 (the official docker image seems to repro) 2. Set up a webhook 3. Trigger the webhook (ie: open a review) # What is the expected output? What do you see instead? Expected: an HTTP request sent from point A to point B Actual: Here is the raw HTTP request that I captured in a pcap: ``` POST /generic-webhook-trigger/invoke?token=SECRET=0 HTTP/1.1 Accept-Encoding: identity Content-Type: application/x-www-form-urlencoded Content-Length: 2656 Host: jenkins User-Agent: Python-urllib/3.8 X-Reviewboard-Event: review_request_published Content-Type: application/json Content-Length: 2656 User-Agent: ReviewBoard-WebHook/4.0rc2 Connection: close ``` As you can see there are duplicate Content-Type headers with different values and duplicate Content-Length headers. The latter makes Apache and Nginx reject the HTTP request. Here is what Apache 2.4.46 logged: ``` Fri Apr 16 21:25:22.156941 2021] [core:debug] [pid 10720:tid 140064923318016] protocol.c(1388): [client 172.18.30.79:47508] AH10242: client sent invalid Content-Length (2656, 2656): /generic-webhook-trigger/invoke [Fri Apr 16 21:25:22.156988 2021] [headers:debug] [pid 10720:tid 140064923318016] mod_headers.c(899): AH01503: headers: ap_headers_error_filter() 0065411356416] mod_headers.c(899): AH01503: headers: ap_headers_error_filter() ``` Here is the log from reviewboard: ``` Traceback (most recent call last): File "/venv/lib/python3.8/site-packages/reviewboard/notifications/webhooks.py", line 398, in dispatch_webhook_event urlopen(Request(url, body, headers)) File "/usr/lib/python3.8/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.8/urllib/request.py", line 531, in open response = meth(req, response) File "/usr/lib/python3.8/urllib/request.py", line 640, in http_response response = self.parent.error( File "/usr/lib/python3.8/urllib/request.py", line 569, in error return self._call_chain(*args) File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain result = func(*args) File "/usr/lib/python3.8/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 400: Bad Request ``` # What operating system are you using? What browser? I'm running Debian 11 + Firefox 87, but I don't think thats relevant ;) # Please provide any additional information below. Here is where the headers are set up: https://github.com/reviewboard/reviewboard/blob/release-4.0rc2/reviewboard/notifications/webhooks.py#L368 The code has been present since RB 2.5.8: https://github.com/reviewboard/reviewboard/commit/975b8e56d928100b6ff9e11a86399435440222e7 The code works in python 2.7 but results in duplicate headers under python 3.6, 3.8, and 3.9. -- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard-issues/20210417024109.1009.21934%40ip-10-1-54-209.ec2.internal.
Re: Review Board Ticket #4194: Include real line numbers for diff comments in API, webhook payloads
-- To reply, visit https://hellosplat.com/s/beanbag/tickets/4194/ -- New update by pawolf For Beanbag, Inc. > Review Board > Ticket #4194 Reply: Hello - Has there been any update on this? Can you tell me if newer versions of ReviewBoard return the real line numbers in the webhook payload and API? We have version 2.5.7 of ReviewBoard and I see there is a 3.0.18 version available. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard-issues/20200904204148.27174.71144%40ip-10-1-54-209.ec2.internal.
Post-Review fails from within script
I have one installation of reviewboard in my laptop(testing) and
another in my workplace.
When running the script in my laptop it runs without any problems.
When running the script in my workplace the script produce the
following error:
RBTools 0.3.4
Home = C:\Users\my-username\AppData\Roaming
svn info
diff --version
repository info: Path: repository-url, Base path: branch-relative-path,
Supports changesets: False
HTTP GETting api/
post-review.exe : Traceback (most recent call last):
At C:\Users\my-username\Desktop\Hooks\Create-Review.ps1:126 char:12
+ $Diff |$PostReview $Arguments;
+ CategoryInfo : NotSpecified: (Traceback (most recent
call last)::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
File C:\python27\Scripts\post-review-script.py, line 8, in
module
load_entry_point('RBTools==0.3.4', 'console_scripts', 'post-
review')()
File C:\Python27\lib\site-packages\rbtools\postreview.py, line
3975, in main
if not server.check_api_version():
File C:\Python27\lib\site-packages\rbtools\postreview.py, line
510, in check_api_version
root_resource = self.api_get('api/')
File C:\Python27\lib\site-packages\rbtools\postreview.py, line
963, in api_get
return self.process_json(self.http_get(path))
File C:\Python27\lib\site-packages\rbtools\postreview.py, line
932, in http_get
rsp = urllib2.urlopen(url).read()
File C:\Python27\lib\urllib2.py, line 126, in urlopen
return _opener.open(url, data, timeout)
File C:\Python27\lib\urllib2.py, line 394, in open
response = self._open(req, data)
File C:\Python27\lib\urllib2.py, line 412, in _open
'_open', req)
File C:\Python27\lib\urllib2.py, line 372, in _call_chain
result = func(*args)
File C:\Python27\lib\urllib2.py, line 1199, in http_open
return self.do_open(httplib.HTTPConnection, req)
File C:\Python27\lib\urllib2.py, line 1174, in do_open
raise URLError(err)
urllib2.URLError: urlopen error [Errno 11004] getaddrinfo failed
I have reviewboard 1.6RC in my laptop and 1.6.3 in my workplace.
Has this happened to anyone else?
Btw when running the exe manually I am able to create/update reviews.
(I don't pipe the diff to the exe when running manually but provide
the full diff path)
Any help would be greatly appreciated.
--
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
Using post-review.exe
Hi,
I finished setting up reviewboard and I wrote a script to use the post-
review.exe
I encountered problems so I executed the exe manually with the
following command in the related branch directory:
Post-Review.exe --server=http://ip-address/reviews/ --
username=super-user --password=super-user-password --submit-as=my-
reviewboard-username --revision-range=1802:1806 -r2 -d
I can see that request 2 exists and (I created it using the exe) but
the result I'm getting is:
RBTools 0.3.4
Home = C:\Users\my-user-name\AppData\Roaming
svn info
diff --version
repository info: Path: svn repository url, Base path:
branches/branch-name, Supports changesets: False
HTTP GETting api/
HTTP GETting http://192.168.1.110/reviews/api/info/
Using the new web API
svn diff --diff-cmd=diff -r 1802:1806
.
.(executing svn info on all of the related files that have been
changed)
.
HTTP GETting http://192.168.1.110/reviews/api/review-requests/2/
Got API Error 101 (HTTP code 403): You don't have permission for this
Error data: {u'stat': u'fail', u'err': {u'msg': uYou don't have permission
for this, u'code': 101}}
Error getting review request 2: You don't have permission for this
(HTTP 403, AP
I Error 101)
If I'm running as a super user than how can that be?
The reviewboard is set up on an apache serve on ubuntu(11.04) and I
ran the exe from windows 7.
In windows 7 I have python 2.7.2 installed along with the win32 gnu
diff tool.
Any help would be much appreciated.
--
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: reviewboard 1.6.1 with wsgi
Yes, I am encountering similar problems. I opened a thread but no one replied. I would love to get a working configuration that will allow me to set up review board as a non root site. On Oct 11, 11:59 am, Rohini Kumar Tharigonda rok...@gmail.com wrote: I am still having the same problem. Any one have the same problem ? On Sep 12, 10:40 am, Rohini Kumar Tharigonda rok...@gmail.com wrote: The following is my configuration.. You can see that i commented #WSGIScriptAlias /reviewboard/ /var/ www/reviewboard/htdocs/reviewboard.wsgi. After doing this it started working. VirtualHost *:80 ServerName localhost DocumentRoot /var/www/reviewboard/htdocs # Error handlers ErrorDocument 500 /errordocs/500.html WSGIPassAuthorization On #WSGIScriptAlias /reviewboard/ /var/www/reviewboard/htdocs/ reviewboard.wsgi WSGIScriptAlias / /var/www/reviewboard/htdocs/reviewboard.wsgi Directory /var/www/reviewboard/htdocs AllowOverride All /Directory # Alias static media requests to filesystem Alias /reviewboard/media /var/www/reviewboard/htdocs/media Alias /reviewboard/errordocs /var/www/reviewboard/htdocs/ errordocs Alias /reviewboard/favicon.ico /var/www/reviewboard/htdocs/media/ rbcommons/images/favicon.png /VirtualHost On Sep 11, 11:37 am, Kannaiyan Natesan gbpnk...@gmail.com wrote: This is my working version. VirtualHost *:80 ServerName internal.nq.corp DocumentRoot /var/www/html/htdocs # Error handlers ErrorDocument 500 /errordocs/500.html WSGIPassAuthorization On WSGIScriptAlias / /var/www/html/htdocs/reviewboard.wsgi Directory /var/www/html/htdocs AllowOverride All /Directory # Alias static media requests to filesystem Alias /media /var/www/html/htdocs/media Alias /errordocs /var/www/html/htdocs/errordocs /VirtualHost On Sun, Sep 11, 2011 at 12:20 AM, Rohini Kumar Tharigonda rok...@gmail.comwrote: Following is the configuration in /var/www/reviewboard/conf/apache-wsgi.conf VirtualHost *:80 ServerName localhost DocumentRoot /var/www/reviewboard/htdocs # Error handlers ErrorDocument 500 /errordocs/500.html WSGIPassAuthorization On WSGIScriptAlias /reviewboard/ /var/www/reviewboard/htdocs/ reviewboard.wsgi Directory /var/www/reviewboard/htdocs AllowOverride All /Directory # Alias static media requests to filesystem Alias /reviewboard/media /var/www/reviewboard/htdocs/media Alias /reviewboard/errordocs /var/www/reviewboard/htdocs/ errordocs Alias /reviewboard/favicon.ico /var/www/reviewboard/htdocs/media/ rbcommons/images/favicon.png /VirtualHost i did ln -s /var/www/reviewboard/conf/apache-wsgi.conf /etc/httpd/conf.d/ reviewboard.conf It was not working . Then i changed WSGIScriptAlias /reviewboard/ /var/www/reviewboard/htdocs/ reviewboard.wsgi to WSGIScriptAlias / /var/www/reviewboard/htdocs/reviewboard.wsgi It started working when i typed http:/localhost/reviewboard/ when i type http:/localhost/ , the should actually show fedora error page. Instead of that , it shows up reviewboard with error message. On Sep 10, 11:13 pm, Christian Hammond chip...@chipx86.com wrote: Can you attach your Apache configuration? Christian On Saturday, September 10, 2011, Rohini Kumar Tharigonda rok...@gmail.com wrote: Hi, I installed reviewboard 1.6.1 on fedora 15. I set site path to /var/www/reviewboard/, site root /reviewboard/ . My expectation is , when i typehttp://localhost/reviewboard/i should get reviewboard home page. But it is not working . When i changed WSGIScriptAlias /reviewboard/ /var/www/reviewboard/htdocs/ reviewboard.wsgi to WSGIScriptAlias / /var/www/reviewboard/htdocs/reviewboard.wsgi in apache configuration it started working . When i typehttp://localhost. It is getting redirected to reviewboard page and displays the following message. The page you were looking for does not exist. If you're pretty sure this page does exist, try logging in and trying again. When i typehttp://localhost. I do not want that reviewboard to show up. What do i need to do ? Thanks, Rohini Kumar -- 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
Installation of a review board site(wsgi) not in root.
Hi, I have an ubuntu machine with an apache server running on it. I have two virtual hosts(bugzilla v4.0 and review board v1.6) they are currently separated by the Server name. Short description of the problem: I want to change the review board conf file(in the sites-available folder) so it would use ServerPath and rewrite rules instead of the aliases that came with the default conf file. Long description of the problem: I have a single ip address and port(external) which gets redirected to the apache server. I want the user to be able to write http://ip-address:port/review and be directed to the review board. At the same time the http://ip-address:port/bugs should redirect the user to the bugzilla site. It seems like the review board installation breaks easily and I couldn't find a proper configuration that achieves the desired results. Btw, during some tests I disabled the review board site but when I went to 127.0.0.1 I was redirected to 127.0.0.1/dashboard/ of course the page that was received was 404 but I am very interested in finding out where is the rule which redirected the request. Thanks in advance for any assistance you can provide. -- 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: problem submitting a diff when directories have been renamed using svn mv
Sure, as soon as google code is fixed. ;-) It's down for me... they've been having a lot of stability issues recently. =( jon On Tue, Oct 26, 2010 at 2:22 PM, Christian Hammond chip...@chipx86.comwrote: I think there's likely a problem due to the diff indicating a change to an existing revision when really that file doesn't exist yet. Off-hand, I have no short-term solution to you aside from doing the modifications in a separate change and not posting the move itself to Review Board. Can you file a bug on this? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Tue, Oct 26, 2010 at 1:37 PM, jon latch...@gmail.com wrote: Any idea guys? jon On Oct 21, 7:16 pm, jon latch...@gmail.com wrote: I renamed a bunch of various directories from 'integ' to 's1' by using 'svn mv' in my working copy as well as edited a bunch of files. I am trying to post a review and it is failing. Here is the post-review -d output as well as svn status. I'm running RB 1.5. post-review --version RBTools 0.2 thoughts? jon svn info diff --version repository info: Path:http://svn.mycompany.com/marin, Base path: /branches/iteration-0004, Supports changesets: False svn propget reviewboard:url /Users/jon/checkout/branches/iteration-0004 svn diff --diff-cmd=diff svn info billing/bin/daily.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/ftp-config.xml svn info acdc/bin/acdc.sh svn info acdc/bin/bidharness.sh svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/integ/env.properties svn info mscm/bin/StartServer svn info mscm/bin/JavaBridge.sh svn info mscm/bin/play.sh svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/s1/env.properties svn info mscm/etc/conf.zend/s1/failoverDB.properties svn info mscm/etc/conf.zend/integ/env.properties svn info mscm/etc/conf.zend/integ/failoverDB.properties svn info mscm/etc/conf/s1/env.properties svn info mscm/etc/conf/s1/failoverDB.properties svn info mscm/etc/conf/s1/datacloudmap.xml svn info mscm/etc/conf/spring-config.xml svn info mscm/etc/conf/schema-upgrade-config.xml svn info mscm/etc/conf/datacloudmap.xml svn info mscm/etc/conf/integ/env.properties svn info mscm/etc/conf/integ/failoverDB.properties svn info mscm/etc/conf/integ/datacloudmap.xml svn info cs/grails-app/conf/spring/resources.xml svn info cs/grails-app/conf/DataSource.groovy svn info cs/src/java/env/s1/env_sentry.properties svn info cs/src/java/env/s1/failoverDB.properties svn info cs/src/java/env/s1/env_csr.properties svn info cs/src/java/env/integ/env_sentry.properties svn info cs/src/java/env/integ/failoverDB.properties svn info cs/src/java/env/integ/env_csr.properties svn info olap_stitch/etc/conf/s1/env.properties svn info olap_stitch/etc/conf/olap_service_config.xml svn info olap_stitch/etc/conf/integ/env.properties svn info olap_stitch/etc/conf/integ/failoverDB.properties svn info billing/bin/daily.sh svn info billing/bin/daily.sh svn info billing/bin/daily.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/ftp-config.xml svn info ftpserver/etc/conf/ftp-config.xml svn info ftpserver/etc/conf/ftp-config.xml svn info acdc/bin/acdc.sh svn info acdc/bin/acdc.sh svn info acdc/bin/acdc.sh svn info acdc/bin/bidharness.sh svn info acdc/bin/bidharness.sh svn info acdc/bin/bidharness.sh svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/integ/env.properties svn info acdc/etc/conf/integ/env.properties svn info acdc/etc/conf/integ/env.properties svn info mscm/bin/StartServer svn info mscm/bin/StartServer svn info mscm/bin/StartServer svn info mscm/bin/JavaBridge.sh svn info mscm/bin/JavaBridge.sh svn info mscm/bin/JavaBridge.sh svn info mscm/bin/play.sh svn info mscm/bin/play.sh svn info mscm/bin/play.sh svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc
problem submitting a diff when directories have been renamed using svn mv
I renamed a bunch of various directories from 'integ' to 's1' by using 'svn mv' in my working copy as well as edited a bunch of files. I am trying to post a review and it is failing. Here is the post-review -d output as well as svn status. I'm running RB 1.5. post-review --version RBTools 0.2 thoughts? jon svn info diff --version repository info: Path: http://svn.mycompany.com/marin, Base path: /branches/iteration-0004, Supports changesets: False svn propget reviewboard:url /Users/jon/checkout/branches/iteration-0004 svn diff --diff-cmd=diff svn info billing/bin/daily.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/ftp-config.xml svn info acdc/bin/acdc.sh svn info acdc/bin/bidharness.sh svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/integ/env.properties svn info mscm/bin/StartServer svn info mscm/bin/JavaBridge.sh svn info mscm/bin/play.sh svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/s1/env.properties svn info mscm/etc/conf.zend/s1/failoverDB.properties svn info mscm/etc/conf.zend/integ/env.properties svn info mscm/etc/conf.zend/integ/failoverDB.properties svn info mscm/etc/conf/s1/env.properties svn info mscm/etc/conf/s1/failoverDB.properties svn info mscm/etc/conf/s1/datacloudmap.xml svn info mscm/etc/conf/spring-config.xml svn info mscm/etc/conf/schema-upgrade-config.xml svn info mscm/etc/conf/datacloudmap.xml svn info mscm/etc/conf/integ/env.properties svn info mscm/etc/conf/integ/failoverDB.properties svn info mscm/etc/conf/integ/datacloudmap.xml svn info cs/grails-app/conf/spring/resources.xml svn info cs/grails-app/conf/DataSource.groovy svn info cs/src/java/env/s1/env_sentry.properties svn info cs/src/java/env/s1/failoverDB.properties svn info cs/src/java/env/s1/env_csr.properties svn info cs/src/java/env/integ/env_sentry.properties svn info cs/src/java/env/integ/failoverDB.properties svn info cs/src/java/env/integ/env_csr.properties svn info olap_stitch/etc/conf/s1/env.properties svn info olap_stitch/etc/conf/olap_service_config.xml svn info olap_stitch/etc/conf/integ/env.properties svn info olap_stitch/etc/conf/integ/failoverDB.properties svn info billing/bin/daily.sh svn info billing/bin/daily.sh svn info billing/bin/daily.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/bin/ftpd.sh svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/s1/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/integ/ftpenv.properties svn info ftpserver/etc/conf/ftp-config.xml svn info ftpserver/etc/conf/ftp-config.xml svn info ftpserver/etc/conf/ftp-config.xml svn info acdc/bin/acdc.sh svn info acdc/bin/acdc.sh svn info acdc/bin/acdc.sh svn info acdc/bin/bidharness.sh svn info acdc/bin/bidharness.sh svn info acdc/bin/bidharness.sh svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/s1/env.properties svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/spring-server-app-config.xml svn info acdc/etc/conf/integ/env.properties svn info acdc/etc/conf/integ/env.properties svn info acdc/etc/conf/integ/env.properties svn info mscm/bin/StartServer svn info mscm/bin/StartServer svn info mscm/bin/StartServer svn info mscm/bin/JavaBridge.sh svn info mscm/bin/JavaBridge.sh svn info mscm/bin/JavaBridge.sh svn info mscm/bin/play.sh svn info mscm/bin/play.sh svn info mscm/bin/play.sh svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/spring-client-config.xml svn info mscm/etc/conf.zend/s1/env.properties svn info mscm/etc/conf.zend/s1/env.properties svn info mscm/etc/conf.zend/s1/env.properties svn info mscm/etc/conf.zend/s1/failoverDB.properties svn info mscm/etc/conf.zend/s1/failoverDB.properties svn info mscm/etc/conf.zend/s1/failoverDB.properties svn info mscm/etc/conf.zend/integ/env.properties svn info mscm/etc/conf.zend/integ/env.properties svn info mscm/etc/conf.zend/integ/env.properties svn info mscm/etc/conf.zend/integ/failoverDB.properties svn info mscm/etc/conf.zend/integ/failoverDB.properties svn info mscm/etc/conf.zend/integ/failoverDB.properties svn info mscm/etc/conf/s1/env.properties svn info mscm/etc/conf/s1/env.properties svn info mscm/etc/conf/s1/env.properties svn info mscm/etc/conf/s1/failoverDB.properties svn info mscm/etc/conf/s1/failoverDB.properties svn info mscm/etc/conf/s1/failoverDB.properties svn info mscm/etc/conf/s1/datacloudmap.xml svn info mscm/etc/conf/s1
Re: starting review #
Are you using memcached? Maybe something with that? On Tue, Oct 12, 2010 at 10:41 AM, mxbraun matthew.br...@intel.com wrote: I was able to wipe the reviews_review database--at least I think I did--and it seemed to be fairly happy for a while. However, shortly thereafter, review creation would time out, even for a single-line diff. I turned on logging and enabled code profiling, but the log showed no new entries when I'd try to create the review. The only thing that the access log showed was a POST operation to /r/ new, which returned with a timeout error code. After receiving the timeout message, I would go to my Outgoing reviews section, and a new review had been created, and was available to me. (FWIW, I've seen this behaviour on the 0.8 beta as well.) Today, the problem has gone away, and I can't reproduce the timeout. I suspected that maybe the database was being backed up, or was otherwise unavailable, but that seems unlikely, as the only thing in it is one or two reviews. If there was a problem, it should have gone away quickly because the backup should have finished quickly. I extended fastcgi's timeout to 60 seconds, but that only increased the amount of time I had to wait for the failure report. Any suggestions for how to proceed in debugging this? While the problem has gone away for the moment, I suspect it shall return. Thanks, m@ On Oct 11, 10:48 pm, Christian Hammond chip...@chipx86.com wrote: Yes, you absolutely want the reviews_reviewrequest table. I assume it's too late to wipe the database for reviews_review? :) Not that that one matters much (it's not often exposed). Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Mon, Oct 11, 2010 at 8:42 PM, mxbraun matthew.br...@intel.com wrote: Jon, Did this really do what you wanted? I find myself in much the same situation, of having an ancient RB implementation in use, setting up a more modern one, and the prospect of either keeping the old one around for some indeterminite amount of time. The question I have is: isn't reviews_review a table of completed reviews? The 'id' field in reviews_review seems to have the auto_increment attribute. Isn't the thing you want to adjust reviews_reviewrequest table, so that the review *request* numbers don't collide with the old ones, rather than the completed review records? . Once I executed ALTER TABLE reviews_reviewrequest 2; I got review requests numbered up that high. (Of course, I changed reviews_reviewrequest *after* changing reviews_review. So now my IDs in the reviews_review table are starting at around 2. Gulp!) Thanks, m@ On Aug 21, 6:48 pm, Jon Stevens latch...@gmail.com wrote: Lol. That confirms my suspicions. No worries, we are fine just mothballing the old release and I'll set the review number to be n+1. Thanks for the help! Jon On Aug 21, 2010, at 11:40 AM, Christian Hammond chip...@chipx86.com wrote: In that case, an upgrade could potentially be tricky... Yeah, might want to just start off with a new install. Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Sat, Aug 21, 2010 at 7:22 AM, Jon Stevens latch...@gmail.com wrote: I'm inheriting this installation so I'm not entirely sure of it's history. I believe that it was essentially a checkout of the source code at some point at least a couple years ago and has never been upgraded. jon On Sat, Aug 21, 2010 at 12:11 AM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, It really depends on how old the version is. Unfortunately, at that time, we didn't really have version numbers that meant anything. Can you tell me how you performed database upgrades on the old install? Was it using the old load-db.py and dump-db.py scripts, or was it using ./manage.py evolve? Also, were you using rb-site? Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Fri, Aug 20, 2010 at 9:05 PM, Jon Stevens latch...@gmail.com wrote: Hi Christian, Thanks for the fast response. I haven't tried upgrading things. I guess I could try that, but I got the impression from somewhere that it would be difficult to do so from the early version that we are currently running. If you think it is worth trying, then that is probably the ideal route. cheers, jon On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, Your plan to use ALTER TABLE should work. review_request_id just holds the current ID. That's what should
Re: starting review #
I ended up just mothballing the old installation on the original server and setting up a new 1.5 on a virtual machine. We now primarily just use the new installation and every once and a while, I hear of people looking back at old reviews on the old server. I forget now, but I had to alter a couple things to get the right autoincrement, but it has been working great. jon On Mon, Oct 11, 2010 at 8:42 PM, mxbraun matthew.br...@intel.com wrote: Jon, Did this really do what you wanted? I find myself in much the same situation, of having an ancient RB implementation in use, setting up a more modern one, and the prospect of either keeping the old one around for some indeterminite amount of time. The question I have is: isn't reviews_review a table of completed reviews? The 'id' field in reviews_review seems to have the auto_increment attribute. Isn't the thing you want to adjust reviews_reviewrequest table, so that the review *request* numbers don't collide with the old ones, rather than the completed review records? . Once I executed ALTER TABLE reviews_reviewrequest 2; I got review requests numbered up that high. (Of course, I changed reviews_reviewrequest *after* changing reviews_review. So now my IDs in the reviews_review table are starting at around 2. Gulp!) Thanks, m@ On Aug 21, 6:48 pm, Jon Stevens latch...@gmail.com wrote: Lol. That confirms my suspicions. No worries, we are fine just mothballing the old release and I'll set the review number to be n+1. Thanks for the help! Jon On Aug 21, 2010, at 11:40 AM, Christian Hammond chip...@chipx86.com wrote: In that case, an upgrade could potentially be tricky... Yeah, might want to just start off with a new install. Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Sat, Aug 21, 2010 at 7:22 AM, Jon Stevens latch...@gmail.com wrote: I'm inheriting this installation so I'm not entirely sure of it's history. I believe that it was essentially a checkout of the source code at some point at least a couple years ago and has never been upgraded. jon On Sat, Aug 21, 2010 at 12:11 AM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, It really depends on how old the version is. Unfortunately, at that time, we didn't really have version numbers that meant anything. Can you tell me how you performed database upgrades on the old install? Was it using the old load-db.py and dump-db.py scripts, or was it using ./manage.py evolve? Also, were you using rb-site? Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Fri, Aug 20, 2010 at 9:05 PM, Jon Stevens latch...@gmail.com wrote: Hi Christian, Thanks for the fast response. I haven't tried upgrading things. I guess I could try that, but I got the impression from somewhere that it would be difficult to do so from the early version that we are currently running. If you think it is worth trying, then that is probably the ideal route. cheers, jon On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, Your plan to use ALTER TABLE should work. review_request_id just holds the current ID. That's what should be auto_increment. I think so long as you do that, you'll see the review request ID number you expect. By the way, what problems did you hit with upgrading? Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Fri, Aug 20, 2010 at 5:47 PM, jon latch...@gmail.com wrote: Apologies if this has been covered before, google didn't seem to have an obvious answer. Is it possible to set a starting review # for a clean install? The issue is that we have a pre-1.0 installation that has been in use for awhile now. Instead of trying to figure out how to upgrade the database, I've just created a fresh new installation (of 1.5rc1) on a fresh new server and we are just going to consider the previous version effectively read-only. But, on the new server, I'd like to start the review number +1 higher than the old server so that we don't have conflicting numbers in svn commit messages. I see that reviews_review.id is auto_increment. I know that I can do: ALTER TABLE reviews_review AUTO_INCREMENT = 100;, but I also see a 'review_request_id' column. What is that used for? Do you see any other issues with this approach? thanks, jon -- Want to help the Review Board project? Donate today athttp:// www.reviewboard.org/donate/ Happy user? Let us know athttp://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email
getting search to work with 1.5 and pylucene
I have RB 1.5 final. I have tried pylucene 3.0.2-1 (which is suggested by the rb docs as being the 'latest' version) I also tried 2.9.3-1 None of these worked. Nothing in the logs. Just a 500 error. I finally got 2.4.1-1 installed and it works. In the configuration, give it the path to the *directory* (not *file*) where you have pylucene creating its indexes. ie, the config option says: The file that search index data should be stored in. Maybe this will save someone some time. -- 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: starting review #
I'm inheriting this installation so I'm not entirely sure of it's history. I believe that it was essentially a checkout of the source code at some point at least a couple years ago and has never been upgraded. jon On Sat, Aug 21, 2010 at 12:11 AM, Christian Hammond chip...@chipx86.comwrote: Hi Jon, It really depends on how old the version is. Unfortunately, at that time, we didn't really have version numbers that meant anything. Can you tell me how you performed database upgrades on the old install? Was it using the old load-db.py and dump-db.py scripts, or was it using ./manage.py evolve? Also, were you using rb-site? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Aug 20, 2010 at 9:05 PM, Jon Stevens latch...@gmail.com wrote: Hi Christian, Thanks for the fast response. I haven't tried upgrading things. I guess I could try that, but I got the impression from somewhere that it would be difficult to do so from the early version that we are currently running. If you think it is worth trying, then that is probably the ideal route. cheers, jon On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond chip...@chipx86.comwrote: Hi Jon, Your plan to use ALTER TABLE should work. review_request_id just holds the current ID. That's what should be auto_increment. I think so long as you do that, you'll see the review request ID number you expect. By the way, what problems did you hit with upgrading? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Aug 20, 2010 at 5:47 PM, jon latch...@gmail.com wrote: Apologies if this has been covered before, google didn't seem to have an obvious answer. Is it possible to set a starting review # for a clean install? The issue is that we have a pre-1.0 installation that has been in use for awhile now. Instead of trying to figure out how to upgrade the database, I've just created a fresh new installation (of 1.5rc1) on a fresh new server and we are just going to consider the previous version effectively read-only. But, on the new server, I'd like to start the review number +1 higher than the old server so that we don't have conflicting numbers in svn commit messages. I see that reviews_review.id is auto_increment. I know that I can do: ALTER TABLE reviews_review AUTO_INCREMENT = 100;, but I also see a 'review_request_id' column. What is that used for? Do you see any other issues with this approach? thanks, jon -- 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 -- 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 -- 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: starting review #
Lol. That confirms my suspicions. No worries, we are fine just mothballing the old release and I'll set the review number to be n+1. Thanks for the help! Jon On Aug 21, 2010, at 11:40 AM, Christian Hammond chip...@chipx86.com wrote: In that case, an upgrade could potentially be tricky... Yeah, might want to just start off with a new install. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Sat, Aug 21, 2010 at 7:22 AM, Jon Stevens latch...@gmail.com wrote: I'm inheriting this installation so I'm not entirely sure of it's history. I believe that it was essentially a checkout of the source code at some point at least a couple years ago and has never been upgraded. jon On Sat, Aug 21, 2010 at 12:11 AM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, It really depends on how old the version is. Unfortunately, at that time, we didn't really have version numbers that meant anything. Can you tell me how you performed database upgrades on the old install? Was it using the old load-db.py and dump-db.py scripts, or was it using ./manage.py evolve? Also, were you using rb-site? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Aug 20, 2010 at 9:05 PM, Jon Stevens latch...@gmail.com wrote: Hi Christian, Thanks for the fast response. I haven't tried upgrading things. I guess I could try that, but I got the impression from somewhere that it would be difficult to do so from the early version that we are currently running. If you think it is worth trying, then that is probably the ideal route. cheers, jon On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond chip...@chipx86.com wrote: Hi Jon, Your plan to use ALTER TABLE should work. review_request_id just holds the current ID. That's what should be auto_increment. I think so long as you do that, you'll see the review request ID number you expect. By the way, what problems did you hit with upgrading? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Aug 20, 2010 at 5:47 PM, jon latch...@gmail.com wrote: Apologies if this has been covered before, google didn't seem to have an obvious answer. Is it possible to set a starting review # for a clean install? The issue is that we have a pre-1.0 installation that has been in use for awhile now. Instead of trying to figure out how to upgrade the database, I've just created a fresh new installation (of 1.5rc1) on a fresh new server and we are just going to consider the previous version effectively read-only. But, on the new server, I'd like to start the review number +1 higher than the old server so that we don't have conflicting numbers in svn commit messages. I see that reviews_review.id is auto_increment. I know that I can do: ALTER TABLE reviews_review AUTO_INCREMENT = 100;, but I also see a 'review_request_id' column. What is that used for? Do you see any other issues with this approach? thanks, jon -- 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 -- 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 -- 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
starting review #
Apologies if this has been covered before, google didn't seem to have an obvious answer. Is it possible to set a starting review # for a clean install? The issue is that we have a pre-1.0 installation that has been in use for awhile now. Instead of trying to figure out how to upgrade the database, I've just created a fresh new installation (of 1.5rc1) on a fresh new server and we are just going to consider the previous version effectively read-only. But, on the new server, I'd like to start the review number +1 higher than the old server so that we don't have conflicting numbers in svn commit messages. I see that reviews_review.id is auto_increment. I know that I can do: ALTER TABLE reviews_review AUTO_INCREMENT = 100;, but I also see a 'review_request_id' column. What is that used for? Do you see any other issues with this approach? thanks, jon -- 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: starting review #
Hi Christian, Thanks for the fast response. I haven't tried upgrading things. I guess I could try that, but I got the impression from somewhere that it would be difficult to do so from the early version that we are currently running. If you think it is worth trying, then that is probably the ideal route. cheers, jon On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond chip...@chipx86.comwrote: Hi Jon, Your plan to use ALTER TABLE should work. review_request_id just holds the current ID. That's what should be auto_increment. I think so long as you do that, you'll see the review request ID number you expect. By the way, what problems did you hit with upgrading? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Aug 20, 2010 at 5:47 PM, jon latch...@gmail.com wrote: Apologies if this has been covered before, google didn't seem to have an obvious answer. Is it possible to set a starting review # for a clean install? The issue is that we have a pre-1.0 installation that has been in use for awhile now. Instead of trying to figure out how to upgrade the database, I've just created a fresh new installation (of 1.5rc1) on a fresh new server and we are just going to consider the previous version effectively read-only. But, on the new server, I'd like to start the review number +1 higher than the old server so that we don't have conflicting numbers in svn commit messages. I see that reviews_review.id is auto_increment. I know that I can do: ALTER TABLE reviews_review AUTO_INCREMENT = 100;, but I also see a 'review_request_id' column. What is that used for? Do you see any other issues with this approach? thanks, jon -- 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 -- 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: Can I send full diffs when publishing the review?
Thanks Christian! Keep up with good work with 1.5 it's working really well. On May 17, 5:24 pm, Christian Hammond chip...@chipx86.com wrote: Hi Jon. I agree that it could be nice on some setups. We might be able to do something down the road for this but not immediately. As for customization of the e-mail template, this is something I would very much like to do in the future. Not for 1.5, but maybe after that. Christian On Friday, May 14, 2010, Jon wuservi...@gmail.com wrote: Hi Christian, I do realize performance could be a concern so I know this wouldn't be for everyone and it would have to be a setting. But for teams that are small enough (server load) and ones that don't send huge chunks of code I think this would be great. One suggestion would be to limit the size of the email and truncate after that but I realize that may be additional work. It does seem like having templates or the ability to customize each email would make this easy to customize. Thanks! On May 14, 1:11 am, Christian Hammond chip...@chipx86.com wrote: Hi Jon, Including the full diff could certainly lead to overly large e-mails in many setups. For example, on a project I've been doing lately, I've had changes that spanned over 60 files with thousands of inserts, deletes and replaces. This would make for really long e-mails, which could increase the load on Review Board and the mail server. The e-mail today includes a link to the diff viewer. We could include a link to the raw diff as well. Would that be sufficient? Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Thu, May 13, 2010 at 8:42 PM, Jon wuservi...@gmail.com wrote: I just setup 1.5 beta 2 with Mercurial and postreview extension and it's working pretty well. However, one thing that people in my group are asking for is a full diff of the entire commit with the diff list in the publish email. I've seen that RB does this when you do a code review so is it easy to make it send the full diffs all the time? I realize they could be big but we tend to do smaller commits and we've been sending out text diffs by email this whole time anyways. Thanks! -- 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...@googlegr oups.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 athttp://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 athttp://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today athttp://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 athttp://groups.google.com/group/reviewboard?hl=en -- -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com -- Want to help the Review Board project? Donate today athttp://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 athttp://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: Can I send full diffs when publishing the review?
Hi Christian, I do realize performance could be a concern so I know this wouldn't be for everyone and it would have to be a setting. But for teams that are small enough (server load) and ones that don't send huge chunks of code I think this would be great. One suggestion would be to limit the size of the email and truncate after that but I realize that may be additional work. It does seem like having templates or the ability to customize each email would make this easy to customize. Thanks! On May 14, 1:11 am, Christian Hammond chip...@chipx86.com wrote: Hi Jon, Including the full diff could certainly lead to overly large e-mails in many setups. For example, on a project I've been doing lately, I've had changes that spanned over 60 files with thousands of inserts, deletes and replaces. This would make for really long e-mails, which could increase the load on Review Board and the mail server. The e-mail today includes a link to the diff viewer. We could include a link to the raw diff as well. Would that be sufficient? Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Thu, May 13, 2010 at 8:42 PM, Jon wuservi...@gmail.com wrote: I just setup 1.5 beta 2 with Mercurial and postreview extension and it's working pretty well. However, one thing that people in my group are asking for is a full diff of the entire commit with the diff list in the publish email. I've seen that RB does this when you do a code review so is it easy to make it send the full diffs all the time? I realize they could be big but we tend to do smaller commits and we've been sending out text diffs by email this whole time anyways. Thanks! -- 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...@googlegr oups.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 athttp://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 athttp://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
